"Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Kelsey on Wed Apr 11 18:14:35 2018
|
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 |
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Hibbard on Thu Apr 12 14:13:18 2018
|
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. |
|
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Stefan Ritt on Sat Apr 14 08:50:40 2018
|
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? |
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Kelsey on Sun Apr 15 08:03:21 2018
|
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 |
|
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Stefan Ritt on Mon Apr 16 08:19:16 2018
|
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 |
Elog ID entry bug at >99999 entries, posted by Joseph McKenna on Fri May 4 14:43:35 2018 
|
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 |
|
Re: Elog ID entry bug at >99999 entries, posted by Andreas Luedeke on Fri May 4 16:05:32 2018
|
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 |
|
Re: Elog ID entry bug at >99999 entries, posted by Chris Rasmussen on Sat May 5 11:22:50 2018
|
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 |