Closed
Bug 26839
Opened 25 years ago
Closed 18 years ago
Bonsai occasionally dropping checkins
Categories
(Webtools Graveyard :: Bonsai, defect, P3)
Webtools Graveyard
Bonsai
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?
Assignee | ||
Comment 1•25 years ago
|
||
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.
Comment 2•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 6•23 years ago
|
||
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).
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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?
Comment 9•23 years ago
|
||
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
Assignee | ||
Comment 10•22 years ago
|
||
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
Assignee | ||
Comment 11•22 years ago
|
||
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
Comment 12•21 years ago
|
||
Is this bug still happening? Also, is a qa still wanted?
Comment 13•21 years ago
|
||
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.
Comment 14•20 years ago
|
||
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.
Reporter | ||
Comment 15•19 years ago
|
||
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.
Reporter | ||
Comment 16•19 years ago
|
||
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.
Updated•18 years ago
|
QA Contact: timeless → bonsai
Comment 17•18 years ago
|
||
This wound up getting fix on bug 331309.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•