ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1149
|
Tue May 17 21:38:36 2005 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.5.9 | Logbook locking issue | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
1165
|
Wed Jun 1 16:14:22 2005 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.5.9 | Re: Logbook locking issue |
Steve Jones wrote: | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
Hmmm, I don't seem to be seeing any responses - is email being generated? |
1166
|
Wed Jun 1 16:33:54 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.5.9 | Re: Logbook locking issue | Sorry about my unusual slow response, but I'm pretty busy these days. I hope I will be able to address this problem in a two weeks from now.
Steve Jones wrote: | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
|
1167
|
Wed Jun 1 21:00:01 2005 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.5.9 | Re: Logbook locking issue |
Steve Jones wrote: | Stefan, not a problem. ITMT, any idea how I can manually clear this "lock"? Is it embedded in the logbook itself?
Stefan Ritt wrote: | Sorry about my unusual slow response, but I'm pretty busy these days. I hope I will be able to address this problem in a two weeks from now.
Steve Jones wrote: | Stefan, any ideas on this problem?
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
|
|
|
1175
|
Sat Jun 4 13:06:08 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.5.9 | Re: Logbook locking issue |
Steve Jones wrote: | Stefan, not a problem. ITMT, any idea how I can manually clear this "lock"? Is it embedded in the logbook itself? |
I would recommend to remove the Restrict edit time = 0.5 temporarily from your config file, then edit this entry, the clicking Back instead of Submit (since you don't really want to edit the entry). This removes the lock, and you can re-enable the Restrict edit time = 0.5 in the config file.
Quote: | Our eLog is set to create logbook entry locks and after 30minutes prevent one from re-editing an entry, thus forcing a REPLY to be created.
SCENARIO: When an *attempt* is made to edit a logbook after the 30minute timer, one gets the message that EDITING is prevented and to use the browser "Back" button.
PROBLEM: The display now shows that particular entry to be locked, even though the attempt to edit was blocked. It appears that the lock flag is set prior to the "Edit" attempt being blocked and thus the lock flag is never "unset". |
I fixed this problem and committed it to CVS. It will be contained in the next release. |
1179
|
Mon Jun 6 12:28:21 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | 2.6.0-beta | elog & firefox pipelining | Having the Firefox pipelining feature enabled makes elog unable to correctly show avery attachment in the full view when a quite large number of them is present..
disabling pipelining makes all works fine again |
1181
|
Mon Jun 6 15:17:50 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.6.0-beta | Re: elog & firefox pipelining |
Emiliano Gabrielli wrote: | Having the Firefox pipelining feature enabled makes elog unable to correctly show avery attachment in the full view when a quite large number of them is present..
disabling pipelining makes all works fine again |
As is said:
Pipelining is an experimental feature, designed to improve page-load performance, that is unfortunately not well supported by some web servers and proxies.
So what do you expect 
I have not checked in detail, but it seems that the browser fires off several requests in parallel, one for each image. This can only be handled by a multi-threaded server, which elog is not (yet). What is more an issue for elog in relation to multi-threading is that one long request blocks all other users. So if I do a synchronize for example from home, the server can be nonresponsive for a minute or two. I have some plans for making it multi-threaded, but as you can imagine this is not so simple to do in a portable way. |
1183
|
Tue Jun 7 13:12:25 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | 2.6.0-beta | Re: elog & firefox pipelining |
Stefan Ritt wrote: |
Emiliano Gabrielli wrote: | Having the Firefox pipelining feature enabled makes elog unable to correctly show avery attachment in the full view when a quite large number of them is present..
disabling pipelining makes all works fine again |
As is said:
Pipelining is an experimental feature, designed to improve page-load performance, that is unfortunately not well supported by some web servers and proxies.
So what do you expect 
I have not checked in detail, but it seems that the browser fires off several requests in parallel, one for each image. This can only be handled by a multi-threaded server, which elog is not (yet). What is more an issue for elog in relation to multi-threading is that one long request blocks all other users. So if I do a synchronize for example from home, the server can be nonresponsive for a minute or two. I have some plans for making it multi-threaded, but as you can imagine this is not so simple to do in a portable way. |
You are right .. I'll wait the m-t support then ghghgh |
|
ELOG V3.1.5-3fb85fa6 |