| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68785
|
Sun Apr 15 08:03:21 2018 |
 | Michael Kelsey | kelsey@slac.stanford.edu | Bug report | Mac OSX | 3.1.3 | Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out | Thank you for your suggestion, Stefan! The sysadmin who handles our e-Log server implemented your suggestion earlier today (Saturday). I have been able to successfully create and modify e-Log entries with Safari since then. Since the "slow script" issue has been intermittent in the past, I plan to continue testing and monitoring for the next day or so. Nevertheless, it appears that removing the waiting loop has alleviated my problem.
-- Mike Kelsey
Followup Sunday 15 Apr (U.S. Pacifiic time): I think your suggestion has solved my problem. I've been able to create and modify e-Log entries through our server multiple times over the weekend. There have been no hangs, timeouts, or lost content. Thank you very much for your response!
| Stefan Ritt wrote: |
|
I'm not 100% sure, but I believe it should work without the
while (in_asend);
So can you please remove that line (it's in src/elogd.c) and recompile elogd and test it?
Stefan
| Michael Hibbard wrote: |
|
I dont' have a solution, but I just wanted to bring more attention to your post. I too am having the same issue with the ELOG system and the Safari browser. I have noticed that ELOG is most stabel and function on the client end from the IE browser. A few weeks ago I also had to switch from using ELOG on the client end from Safari to Firefox.
| Michael Kelsey wrote: |
|
Hello! The CDMS collaboration is using e-Log as one of it's issue tracking systems. In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4): The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever. This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.
Now, I am also seeing the same problems with Firefox, but at the "occasional" level. The difference is that Firefox produces some diagnostic information, which is why I'm posting here. When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:
Warning: unresponsive script
A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.
Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30
[] Don't ask me again
[Debug script] [Stop script] [Continue]
If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:
16 var in_asend = false;
17
18 function chkform()
19 {
20 if (last_key == 13) {
21 var ret = confirm('Really submit this entry?');
22 if (!ret) {
23 last_key = 0;
24 return false;
25 }
26 }
27
28 if (autoSaveTimer != null)
29 clearTimeout(autoSaveTimer);
30 while (in_asend); <=== This is the stuck line
31 submitted = true;
32 return true;
33 }
I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.
Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?
|
|
|
|
|
68786
|
Mon Apr 16 08:19:16 2018 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 3.1.3 | Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out | Ok, I removed the code from the official code now.
A bit background: The "autosave" mechanism in elog saves regularly the current content in a "draft" message, so that the data does not get lost if the browser for example crashes. The saving is done asynchronously via some AJAX call. This call takes some time, since it's a round-trip to the elogd server. If the user hist "submit" during such a save, the second save might be issue before the first one has been finsihed. That's why I had a "while (in_asend)" in the code, where in_asend gets set to true when the AJAX call is started and false when it completes. Now JavaScript is not really multi-threading, so having a loop "while (in_asend)" can actually prevent the AJAX request to complete. This might have been different when I implemented that feature, which is the reason that it worked before. Without that code, it can now happen that a second HTTTP POST is sent before the first request finishes, but I guess this should not be a problem, since both requests come sequentially to the elogd server and are executed one after the other. So in worst case the elog entry text is just saved twice.
| Michael Kelsey wrote: |
|
Thank you for your suggestion, Stefan! The sysadmin who handles our e-Log server implemented your suggestion earlier today (Saturday). I have been able to successfully create and modify e-Log entries with Safari since then. Since the "slow script" issue has been intermittent in the past, I plan to continue testing and monitoring for the next day or so. Nevertheless, it appears that removing the waiting loop has alleviated my problem.
-- Mike Kelsey
Followup Sunday 15 Apr (U.S. Pacifiic time): I think your suggestion has solved my problem. I've been able to create and modify e-Log entries through our server multiple times over the weekend. There have been no hangs, timeouts, or lost content. Thank you very much for your response!
| Stefan Ritt wrote: |
|
I'm not 100% sure, but I believe it should work without the
while (in_asend);
So can you please remove that line (it's in src/elogd.c) and recompile elogd and test it?
Stefan
| Michael Hibbard wrote: |
|
I dont' have a solution, but I just wanted to bring more attention to your post. I too am having the same issue with the ELOG system and the Safari browser. I have noticed that ELOG is most stabel and function on the client end from the IE browser. A few weeks ago I also had to switch from using ELOG on the client end from Safari to Firefox.
| Michael Kelsey wrote: |
|
Hello! The CDMS collaboration is using e-Log as one of it's issue tracking systems. In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4): The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever. This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.
Now, I am also seeing the same problems with Firefox, but at the "occasional" level. The difference is that Firefox produces some diagnostic information, which is why I'm posting here. When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:
Warning: unresponsive script
A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.
Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30
[] Don't ask me again
[Debug script] [Stop script] [Continue]
If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:
16 var in_asend = false;
17
18 function chkform()
19 {
20 if (last_key == 13) {
21 var ret = confirm('Really submit this entry?');
22 if (!ret) {
23 last_key = 0;
24 return false;
25 }
26 }
27
28 if (autoSaveTimer != null)
29 clearTimeout(autoSaveTimer);
30 while (in_asend); <=== This is the stuck line
31 submitted = true;
32 return true;
33 }
I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.
Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?
|
|
|
|
|
|
68792
|
Fri May 4 14:43:35 2018 |
 | Joseph McKenna | joseph.mckenna@cern.ch | Bug report | Linux | 2.9.2 | Elog ID entry bug at >99999 entries | We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision |
|
68793
|
Fri May 4 16:05:32 2018 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
68794
|
Sat May 5 11:22:50 2018 |
| Chris Rasmussen | chris.rasmussen@cern.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
68795
|
Sat May 5 20:55:23 2018 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | Well, in my example the ID link worked just fine.
There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.
Cheers, Andreas
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
68796
|
Mon May 7 14:24:18 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | As Andreas said we have to reproduce the problem. What is special in your case is the elog:SequencerEvents/XXXXX. This is non-standard and must be created through your configuration of elog or by an external script. I just guess that you have something like
Preset ID = elog:SequencerEvents/#####
which causes elog to preset the ID with the above string. Can it be that you just put five hashmarks in the preset?
Stefan
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
68797
|
Mon May 7 18:10:20 2018 |
| Chris Rasmussen | chris.rasmussen@cern.ch | Bug report | Linux | 2.9.2 | Re: Elog ID entry bug at >99999 entries | ah yes, that was a helpful clue. Our elogd.cfg file led me to a .js file which redefines the ID to the elog:SequencerEvents/XXXXX format and it indeed had a silly hard coded length of that string.
Since I am pretty sure this is our code, I think it is safe to say that this is not a bug in the elog
| Andreas Luedeke wrote: |
|
Well, in my example the ID link worked just fine.
There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.
Cheers, Andreas
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
|