[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New rtag-created branch: first client action causes 'protocol er ror'
From: |
Vanderputten_Jennifer |
Subject: |
New rtag-created branch: first client action causes 'protocol er ror' |
Date: |
Wed, 15 Aug 2001 14:40:56 -0400 |
I posted the following to fa.info-cvs, and I wanted to send this to you as a
cvs bug submission.
----------------------------------------------------------------------------
-
I have some information on this problem that may help to locate the root
cause.
I have recently done loadtesting of branch creation (rtag) and
checkout/checkin
usage of the resulting new branches. The loadtest created 500 new branches
from a seperate base branch. It then attempted to checkout, one at a time,
one
of the new branches, then add whitespace and checkin. It does this
linearly;
i.e., branch1 then branch2 and so on. I noticed that the very first
checkout
after a new branching (rtag command) ALWAYS got the protocol error. Any
checkouts after that, though, have worked without a hitch; also, if I did a
checkout once, then did a sleep of a few seconds, then attempted again, the
second was always successful. This begs to be a timing issue.
Not knowing much of the details of CVS server internals, and not having
looked
thoroughly at that code yet, I am taking an educated guess that there is
some
sort of one-time data creation performed upon the very first command against
a new branch. I am further deducing that this is in a seperate child
process,
which is not finishing with that task before the child associated with the
client's request is finished. This results in a lack of needed data by the
client's child at the moment that it expects to find that clump of data,
hence
the protocol error. This is why waiting a moment after this first try, then
trying again, results in success; the first child doing the special one-time
processing is given time to finish. I say one-time processing because this
never happens again to the same branch.
I have taken a look at the cvs codebase for 1.11.1p1 and found that a
particular
change made since the last revision is convincingly tied into this problem.
A
particular chunk of code was removed from a loop that forced it to wait on a
relevant event -- this was done, apparently, to fix a problem of
overextended
waits in particular cases (or possibly infinite loop?). However, it may
have
actually opened the door for this problem -- and indeed, this problem may
also
be a 'particular' case, as mentioned in previous postings, with very large
code bases/modules. That would certainly explain why some child process is
taking unusually long to finish generating some needed data.
The code to which I refer is to be found in server.c. It was removed from
the
main loop (I have this as being lines 2909 - 3130 in function
do_cvs_command):
while (stdout_pipe[0] >= 0
|| stderr_pipe[0] >= 0
|| protocol_pipe[0] >= 0
|| count_needed <= 0)
{
.
.
.
}
Here is the code chunk that was removed (I have this as lines 3132 - 3149):
/*
* OK, we've gotten EOF on all the pipes. If there is
* anything left on stdoutbuf or stderrbuf (this could only
* happen if there was no trailing newline), send it over.
*/
if (! buf_empty_p (stdoutbuf))
{
buf_append_char (stdoutbuf, '\n');
buf_copy_lines (buf_to_net, stdoutbuf, 'M');
}
if (! buf_empty_p (stderrbuf))
{
buf_append_char (stderrbuf, '\n');
buf_copy_lines (buf_to_net, stderrbuf, 'E');
}
if (! buf_empty_p (protocol_inbuf))
buf_output0 (buf_to_net,
"E Protocol error: uncounted data discarded\n");
I hope this can shed some light on the problem. Timing issues are always
very difficult to pinpoint and fix.
--Jen (BIRT)
919-248-6309
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- New rtag-created branch: first client action causes 'protocol er ror',
Vanderputten_Jennifer <=