Closed Bug 26839 Opened 25 years ago Closed 18 years ago

Bonsai occasionally dropping checkins

Categories

(Webtools Graveyard :: Bonsai, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 331309

People

(Reporter: Chris.Yeh, Assigned: tara)

References

Details

(Keywords: helpwanted, qawanted)

About every month or so, I get reports of Bonsai not recording checkins into the sql database. The only vague pattern I've noticed is that all of these checkins are made to a branch. I suspect that dolog.pl is failing for certain branch revision numbers. This is bad, since you can't actually notice when a checkin got dropped until weeks later. I don't know how you would go tracking this down, short of writing a perl script that mimicks a lot of branch traffic with random revision numbers that repeatedly calls dolog.pl into a clean database, and then compare. It's also possible that it's not handling race conditions. Are there any other reports from other Bonsai users?
Priority: P3 → P1
At Blue Martini, this behavior is not limited to a branch, but is also sporadic enough as to be unclear as to the cause. However, we are noticing the drop right away as developers notice when they're checkins are not reflected against the Tinderbox "guilty" column. Will continue to try and narrow this down.
Hey! Don't go mucking with the "priority" field; it belongs to the assigned engineer to help them decide what order they will fix things. One way to track this down is when you see a checkin failed, go grovel through all the zillions of temp.* files that gets created in Bonsai's data directory. Each one of those files is created when bonsai receives a mail message from dolog.pl. It contains exactly the mail message that was received. So, if someone tells you a checkin didn't show up, you can go get the checkin message from CVS, and then grep for that comment in all the temp.* files. If can't find the message, then maybe dolog.pl hasn't sent it. If you do find it, then attach it here (along with the relevant section of "cvs log" for that file), and maybe I can figure out if dolog.pl is generating the wrong thing.
Status: NEW → ASSIGNED
Priority: P1 → P2
how long does Bonsai keep the .tmp files lying around? i just did what you suggested (doing a grep for the comment in the data directory) on a blown checkin on Feb 1st, and it returned nothing.
Nothing inherent in Bonsai ever removes them. But you may be running a cron job that cleans them up. Look at the modification times of the temp.* files in your directory and see if there are other files at around the time of the change you're looking for.
tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
I have noticed this when (re)building the checkins from scratch. There seems to be a series of checkins that just don't make it to the database. If I rebuild the checkins the same ones are missing every time (as far as I can tell).
I found the problem in my particular cas. It seems an entry in the repositories table was created every time I rebuilt the databse and it was this that was causing the missing checkins as they were added to this non existant repository.
This happens with me too, and always when one user does a bunch of checkins together. However, I lost the checkin messages generated because there is an unlink() call in handleCheckinMail.pl. I've commented it out so I can check what on earth is going on. Gareth, you said you tracked it down - any idea what was going on?
Sorry about the slow reply, As I said I am not sure if the problem I discovered was particular to me alone but... I noticed that when I built the checkins database the first time (and on subsequent rebuilds) a new record was added to the repositories table.(where it got this value from I do not know and have not tried to track down) It seems that the 'missing' checkins were added to this non-existant repository. I just changed all the checkins to point to the correct repository and deleted the incorrect entry from the repositories table and it has not happned since (I have not rebuilt again though)
Keywords: helpwanted, qawanted
QA Contact: timeless
This isn't reproducible in any kind of consistant way, and frankly, haven't seen it on several installations. Leaving it open, but downgrading.
Severity: critical → minor
Priority: P2 → P3
A recent #mozwebtools discussion determined that at least one cause to this is in fact related to mail problems on the server. At least this part of it (and maybe this will end up being the whole problem) will get addressed when the email interface into the checkin db goes away. Re-upping severity now that we have more info, but leaving priority for now.
Severity: minor → normal
Is this bug still happening? Also, is a qa still wanted?
I'm not sure. Nothing I heard of makes me conclude one way or the other. By "want QA" what do you mean? If you mean that you can volunteer time to reproduce this on a local installation, by all means, yes.
FYI, I tracked one symptom of this problem back to the fact that we're not escaping filenames when invoking a system shell (bug 258668). And I recommend trying out the patch in bug 244801 to avoid the email issue.
Depends on: 259248
No longer depends on: 259248
Apparently I'm just really lucky or something, because I have a new bonsai installation that will occasionally drop checkins on branches. This is truly annoying. As the original reporter 6 years ago, I find it amusing that this _still_ happens. Same info as last time. Mostly it's happening on checkins to a branch. We are using newer hardware which is pretty fast, so again I'm wondering if there is a race condition going on of some kind.
Oh, I should also point out that this has happened whether I used the email interface or not. I.E. whether using the mail mechanism or by calling handleCheckinMail.pl. Using either method will occasionally drop a checkin.
Depends on: 335735
QA Contact: timeless → bonsai
This wound up getting fix on bug 331309.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.