Hi Stephen,

I see that you don't allow branching in your threads.  Why do you need to propagate the Status throughtout the thread?  Why not just mark the latest entry and (incase it is necessary) 'collapse to last = 1'

I'm not saying that the bug (if bug it is, rather than a preset limitation) you've found should not be fixed, but I'm puzzled as to why you happen to use the feature.  I can see the point if an initial entry provides a whole tree of branches (and a limit of 10 is rather limiting).  OK, I know if it is historic, it cannot easily be changed because of other users.  Or if some users will primarily be responding to emails rather viewing the logbook via a browser.  I'm a single (ab)user elog system myself, so I'm very tolerant of changing how elog works if it offers an improvement.

Using Elog 2.9.2

Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.

I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies.  On the 10th reply the application crashed, this is repeatable 100% of the time.  Without the propagate option everything works fine.

Attached is my config file parsed down.

Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?

 Having written the above and posted it, I see the links for ECP&SIW I wrote here don't work the same as in my local logbook.  I did check!  Result is treat the above posting with caution.  Although this is not the first time when something works fine on my local logbook but not here on the Mother of all elogs.  Different flavour of linux?

 Years ago I had a similar issue, although I cannot remember the exact details now.  The consequence is that I don't leave any spaces in the log book names.  However, I did find that '&' was fine, and the ampersand and %26 are interchangeable in a logbook page, so one logbook is ECP&SIW, and using ampersand or '%26' work interchangably when making llinks from other logbooks to ECP&SIW  (that is elog:ECP&SIW or elog:ECP%26SIW work equally well)..    This is not true of elog.cfg, where only the actual character should be used.  This may be true for some other urlencoded characters.

It may be of note that %20 and '+' are not the same urlencode and character - %20 is a space, '+' is %2B, and a brief bit of playing around shows that elog is not so tolerant of those characters as it is with & and %26, and I crashed mine several times but I was only playing, nothing serious was lost.

Can you be a bit more specific which buttons you mean? The demo logbook https://midas.psi.ch/elogs/Linux+Demo/ has also a space and I cannot see any problem there.

My elog is named "Whatever Elog" so the URL generated is /Whatever+Elog . This works fine but when in the interface certain buttons generate this URL : /Whatever%20Elog  ...this URL fails.  It seems that elog does not recognize these ( + and %20 ) as the same which I believe they should be as part of HTTP request.

Yes, unwanted characters are in my file.  In fact, they are not visible under some editor.  So, I have found a reference from this site http://www.ventrino.com/blog/60/2008/07/three-little-characters-i%C2%BB%C2%BF-designed-to-make-your-life-hell/ about how to remove them.  Basically, file's properties has to set to either ASCII or Encode as UTF-8 without BOM.  Thanks.

> > I'm not an expert in debugging web applications. Here are my two cent:
> > We once had a problem when we hosted very large logbooks (several 10 thousands of entries) that the server would run
> > out of real memory and was slowed down by swapping. Therefore my first idea would be to monitor the server: Is
> > the CPU load peaking? What happens with the memory consumption? Any other suspicious process running on the server?
> > But it could be as well a network or browser problem. Did you try different browsers?
> > Did you check the elogd log file?
> 
> The logbook only has a few hundred entries, elogd is using only around 20-30 MB and there is enough free RAM. The load 
> average for the server is around 0.2, elogd only uses 5% CPU at most when it is accessed and the CPU is idle most of the 
> time. 
> 
> Strangely it happens mostly when using Chrome, and almost never with Firefox. I captured the network traffic, but I can't 
> see anything unusual. It just takes very long until the answer is returned by the elogd server.

My tuppance worth.  I have noticed (firefox) that some attachments take rather longer than might be expected to upload.  I
originally thought this was the ghostview program processing say a pdf to make pngs etc, but have more recently started to
question that assumption.  No solution or much clue, just another observation.