| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69147
|
Sun May 3 22:43:12 2020 |
 | Frank Baptista | caffeinejazz@gmail.com | Question | Windows | V3.1.4-80633ba | Re: Record ID corruption | Hi David,
Thanks for the quick response! Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure.
This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.
Thanks,
Frank
| David Pilgram wrote: |
|
Hi,
I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file. It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot. If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached. Not so sure about such an event here unless entry 5658 were already open but not closed?
Regards,
David.
| Frank Baptista wrote: |
|
Hi all,
I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.
In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber). We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.
What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....
Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.
Has anyone else encountered this?
Thanks,
Frank
|
|
|
| Attachment 1: 200428a.log
|
$@MID@$: 5653
Date: Tue, 28 Apr 2020 00:02:42 -0400
Reply to: 5654
In reply to: 5652
Clock #: N31419
Type: Test
Category: Update
Perform OPM?:
ATMS Correct?:
Station Down?:
Test End?: No
Production Status: Production
Attachment:
Encoding: HTML
========================================
<p>CYCLE 14 @ COLD -54 C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 14 @ COLD -54 C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 13 @ Hot; +85°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 13 @ Cold; -54°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 13 @ Cold; -54°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 12 @ Hot; +85°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 12 @ Hot; +85°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 12 @ Cold; -54°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>Cycle 12 @ Cold; -54°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 11 OF 25 @ HOT +85°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 11 OF 25 @ HOT +86°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 11 OF 25 @ HOT +86°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 11 OF 25 @ COLD -54°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 10 OF 25 @ RAMPING TO COLD.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 10 @ HOT +85°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 10 @ COLD -54°C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 10 @ COLD, -55C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 9 @ HOT, +85C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 9 @ HOT, +85C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 9 @ COLD, -54C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 8 @ HOT, +85C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 8 @ HOT, +85C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 8 @ HOT, +86C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 8 @ COLD, -54C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 8 @ RAMPING TO COLD, -38C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 7 @ HOT, +85C.</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 7 @ HOT,+85C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 7 @ COLD, -54C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 7 @ COLD, -54C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 6 @ HOT, +85C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 6 @ HOT, +85C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
</tr>
<tr>
<td style="background-color: rgb(255, 255, 176);">
<p>CYCLE 6 @ COLD, -54C</p>
<table align="center" cellspacing="1" style="border-image:none; border:1px solid rgb(72, 96, 144); width:98%">
<tbody>
<tr>
<td style="background-color: rgb(72, 96, 144);">Quote:</td>
... 7288 more lines ...
|
|
69148
|
Mon May 4 14:55:53 2020 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Windows | V3.1.4-80633ba | Re: Record ID corruption | Hi Frank,
There are two interesting points about the log file.
1. Entry 5658 is timestamped later than 5659, but is earlier in the entry list. It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is. Might this be a feature of the draft function? I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.
2. Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should Again, this might be a feature of the draft function
Could someone be confusing a draft entry with a real one? Or two attempts to make an entry?
On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th. This leaves an orphan thread that causes other issues. Do you have enough information to decided that this event always happens after x replies?
| Frank Baptista wrote: |
|
Hi David,
Thanks for the quick response! Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure.
This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.
Thanks,
Frank
| David Pilgram wrote: |
|
Hi,
I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file. It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot. If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached. Not so sure about such an event here unless entry 5658 were already open but not closed?
Regards,
David.
| Frank Baptista wrote: |
|
Hi all,
I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.
In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber). We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.
What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....
Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.
Has anyone else encountered this?
Thanks,
Frank
|
|
|
|
|
69151
|
Fri May 22 21:03:05 2020 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | V3.1.4-80633ba | Re: Record ID corruption | Hi David,
Well, you've made some very interesting observations, and raised some excellent questions. So, I went back and did some homework, reviewing a number of logbooks to find instances where this strange 'record twist' occurs. You had asked, "Do you have enough information to decided that this event always happens after x replies?" -- and to my surprise, indeed there was a magic number that I didn't expect to see. The 57th reply to the original posting was always where the corruption began. Mind you, we don't always get a corruption on the 57th reply -- most of the time, it works as expected. However, in all the cases where I saw this record twist, it was the 57th reply after the original posting. Go figure.
I also reviewed my elogd.cfg file to see how I handled drafts. Currently, it does have the flag Save drafts = 0. What I plan to try next, if only to satisfy my curiosity, is to also add Autosave=0.
I can't thank you enough for your time and feedback...very much appreciated!
Best regards,
Frank
| David Pilgram wrote: |
|
Hi Frank,
There are two interesting points about the log file.
1. Entry 5658 is timestamped later than 5659, but is earlier in the entry list. It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is. Might this be a feature of the draft function? I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.
2. Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should Again, this might be a feature of the draft function
Could someone be confusing a draft entry with a real one? Or two attempts to make an entry?
On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th. This leaves an orphan thread that causes other issues. Do you have enough information to decided that this event always happens after x replies?
| Frank Baptista wrote: |
|
Hi David,
Thanks for the quick response! Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure.
This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.
Thanks,
Frank
| David Pilgram wrote: |
|
Hi,
I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file. It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot. If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached. Not so sure about such an event here unless entry 5658 were already open but not closed?
Regards,
David.
| Frank Baptista wrote: |
|
Hi all,
I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.
In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber). We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.
What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....
Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.
Has anyone else encountered this?
Thanks,
Frank
|
|
|
|
|
|
69152
|
Sat May 23 16:15:38 2020 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Windows | V3.1.4-80633ba | Re: Record ID corruption | Hi Frank,
Good bit of detective work. To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue. If that "something" hasn't happened, all is well. Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding. My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.
I'm trying to think what this something might be. With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever. Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.
Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up. Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug. So, I've been right on more than one occasion. Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply?
Another line would be to view the yymmdda.log files while you are making a normal reply. In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created. Is that still true with your version? I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where? That Autosave =0 looks to be a useful test to do.
Sorry I cannot be more help. I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well. but I do have some experience in bug finding!
David.
| Frank Baptista wrote: |
|
Hi David,
Well, you've made some very interesting observations, and raised some excellent questions. So, I went back and did some homework, reviewing a number of logbooks to find instances where this strange 'record twist' occurs. You had asked, "Do you have enough information to decided that this event always happens after x replies?" -- and to my surprise, indeed there was a magic number that I didn't expect to see. The 57th reply to the original posting was always where the corruption began. Mind you, we don't always get a corruption on the 57th reply -- most of the time, it works as expected. However, in all the cases where I saw this record twist, it was the 57th reply after the original posting. Go figure.
I also reviewed my elogd.cfg file to see how I handled drafts. Currently, it does have the flag Save drafts = 0. What I plan to try next, if only to satisfy my curiosity, is to also add Autosave=0.
I can't thank you enough for your time and feedback...very much appreciated!
Best regards,
Frank
| David Pilgram wrote: |
|
Hi Frank,
There are two interesting points about the log file.
1. Entry 5658 is timestamped later than 5659, but is earlier in the entry list. It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is. Might this be a feature of the draft function? I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.
2. Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should Again, this might be a feature of the draft function
Could someone be confusing a draft entry with a real one? Or two attempts to make an entry?
On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th. This leaves an orphan thread that causes other issues. Do you have enough information to decided that this event always happens after x replies?
| Frank Baptista wrote: |
|
Hi David,
Thanks for the quick response! Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure.
This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.
Thanks,
Frank
| David Pilgram wrote: |
|
Hi,
I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file. It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot. If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached. Not so sure about such an event here unless entry 5658 were already open but not closed?
Regards,
David.
| Frank Baptista wrote: |
|
Hi all,
I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.
In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber). We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.
What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....
Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.
Has anyone else encountered this?
Thanks,
Frank
|
|
|
|
|
|
|
69193
|
Tue Aug 4 13:38:05 2020 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | V3.1.4-80633ba | Re: Record ID corruption | I tried to reproduce the problem with a fresh minimal logbook (the demo one coming from the distribution). Made 60 replies and all went well. So I wonder if it has to do with some special settings in elogd.cfg. Can you reproduce the problem with an empty logbook and an edlog.cfg which contains just the minimal settings?
| David Pilgram wrote: |
|
Hi Frank,
Good bit of detective work. To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue. If that "something" hasn't happened, all is well. Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding. My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.
I'm trying to think what this something might be. With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever. Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.
Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up. Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug. So, I've been right on more than one occasion. Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply?
Another line would be to view the yymmdda.log files while you are making a normal reply. In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created. Is that still true with your version? I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where? That Autosave =0 looks to be a useful test to do.
Sorry I cannot be more help. I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well. but I do have some experience in bug finding!
David.
| Frank Baptista wrote: |
|
Hi David,
Well, you've made some very interesting observations, and raised some excellent questions. So, I went back and did some homework, reviewing a number of logbooks to find instances where this strange 'record twist' occurs. You had asked, "Do you have enough information to decided that this event always happens after x replies?" -- and to my surprise, indeed there was a magic number that I didn't expect to see. The 57th reply to the original posting was always where the corruption began. Mind you, we don't always get a corruption on the 57th reply -- most of the time, it works as expected. However, in all the cases where I saw this record twist, it was the 57th reply after the original posting. Go figure.
I also reviewed my elogd.cfg file to see how I handled drafts. Currently, it does have the flag Save drafts = 0. What I plan to try next, if only to satisfy my curiosity, is to also add Autosave=0.
I can't thank you enough for your time and feedback...very much appreciated!
Best regards,
Frank
| David Pilgram wrote: |
|
Hi Frank,
There are two interesting points about the log file.
1. Entry 5658 is timestamped later than 5659, but is earlier in the entry list. It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is. Might this be a feature of the draft function? I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.
2. Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should Again, this might be a feature of the draft function
Could someone be confusing a draft entry with a real one? Or two attempts to make an entry?
On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th. This leaves an orphan thread that causes other issues. Do you have enough information to decided that this event always happens after x replies?
| Frank Baptista wrote: |
|
Hi David,
Thanks for the quick response! Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure.
This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.
Thanks,
Frank
| David Pilgram wrote: |
|
Hi,
I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file. It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot. If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached. Not so sure about such an event here unless entry 5658 were already open but not closed?
Regards,
David.
| Frank Baptista wrote: |
|
Hi all,
I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.
In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber). We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.
What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....
Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.
Has anyone else encountered this?
Thanks,
Frank
|
|
|
|
|
|
|
|
69357
|
Mon Apr 26 16:41:50 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
69360
|
Fri Apr 30 20:29:45 2021 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hi Sebatian,
Thank you for taking the time to answer...very much appreciated!
Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.
Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing. All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location. Users can view all the logbooks on one screen, by connecting to the mirror server. Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers. As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.
I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.
In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.
Cheers,
Frank
| Sebastian Schenk wrote: |
|
Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
|
69361
|
Fri Apr 30 21:13:39 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hi Frank,
I am not sure, if I understood your setup correctly. But in my eyes, you don't need the local elog servers. The only difference for the users at the chambers would be to directly use the 'mirror' remote elog url instead of the local elog url in their browsers. "which is regularly updated..." could mean, that you are using some kind of automatism to add entries to the local elogs, but you could also use these directly on the remote
If you have concers about users editing the wrong chamber elog, there is a usermanagement to only allow certain users to certain elogs (on the remote).
As for the part "having a record conflict". That would be totally fine and handled by the mirror function.
See the part "If new entries exist locally and remotely having the same entry ID"... in the documentation of the function.
As you state, that you are working on windows. There is no "killall" command to send the signal, as far as i know.
Then a script could kill the elog and start it again. But this should have the disadvantage of loosing the login session of the users.
Best wishes,
Sebastian
| Frank Baptista wrote: |
|
Hi Sebatian,
Thank you for taking the time to answer...very much appreciated!
Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.
Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing. All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location. Users can view all the logbooks on one screen, by connecting to the mirror server. Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers. As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.
I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.
In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.
Cheers,
Frank
| Sebastian Schenk wrote: |
|
Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
|
|