It's here. 

Ah, the GET /nor/elog.rdf gave me somt hint: Your Firefox browser checks the RSS feed of elog regularly. If the logbook is empty, the routing producing the elog.rdf file went into some kind of infinite loop, but this only happens on an empty logbook. If fixed this and updated the 276-2 file just now, so try again.

Thanks for your help

Hi,

I need more information to narrow down the problem:

- does this only happen on automatic mirroring or also when you do a manual synchronize?

- does this happen on both sides, like when you make the "other" elog server the master?

- if the server is inresponsive, does the CPU on that machine go to 100% or to 0%?

- do you have very long attachments in your logbooks?

- do you have the same problem on a "tiny" logbook like it comes with the distribution?

- are you using any Apache proxy in between?

I'm afraid that in the end you have to debug this yourself, since it will be very hard for me to reproduce exactly your problem (unless you send me all your files). 

Cheers,

  Stefan

Stefan,

Thanks for the reply.

This happens on automatic mirroring and by manual sync. However only the site initializing the mirror is locked out the remote seems to still be able to function.

The CPU jumps from very little usage to 50%+ being used by elogd.exe as soon as you start the mirroring/sync process

I have attached a file that that is in three parts and its pretty big. When I start up the elogd -v it takes over two minutes to scroll through hundreds of  files. I have attached the last of those entries in the first part of the attached PDF, the second part of the PDF shows a manual sync and the third part shows the same sync on the same logbook a few mins later. It seems to take about 3 minutes even when there has been no new log entries. In addition if you are mirroring more that one log book through the automated cron job it can take about 3-5 mins before the second logbook starts its replication. I have also added a screenshot of the completed replications on both runs.

If there is a way to redirect the output of the cmd window when running elogd -v I would capture all the data for you but the standard redirect ">> elog.txt" only creates a blank file.

We are running several logbooks and it does look like the smaller logbooks still take several minutes to start up. I have attached the PMCLogfile and if you look between the NSS and the AMC replications on any day there seems to be a 3 min gap between one book finishing and another starting.

We are not using Apache prox in between.

I am not a programmer but I can follow instruction, if you need anything else let me know.

Stefan this has been driving me nuts for a while now so any help you can give would be more than appreciated.

Cheers,

Lance

When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment.  This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.

Suggested patch follows.

Change "s%d" to "c%d" in lines 9675 and 9678.

Showing lines 9675-9680 below, change from:

               rsprintf("  if (document.form1.s%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.s%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

to:

               rsprintf("  if (document.form1.c%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.c%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

Regards,

Richard Stamper

This is absolutely correct, even the right fix. I put that into the distribution. Thanks a lot.