Hi,
On Fri, May 11, 2012 at 09:49:36AM +0000, Greg Stein wrote:
> On Thu, May 10, 2012 at 08:57:33PM +0200, Andreas Mohr wrote:
[...]
> I ran into an SvnBridge bug a few years ago. AFAIK, they still have
> not fixed it, despite my pointer to the specific line in the bridge
> code causing the problem.
>
> Codeplex is not exactly well-maintained :-(
Oh hell yeah indeed. And a pretty terrible community development interface
(e.g. patch files will get *removed* from public view once they're rejected,
e.g. for "outdated patch, please update" reasons - well then how to ever get
it updated??).
> >...
> > Anyway, more details:
> > That obviously seems to be a problem with parsing/transmission of
> > HTTP Chunked Transfers
> > (and BTW another abort also happened with a "SVN: Malformed XML" error
> > on another svn operation).
>
> Well, if the connection somehow indicates EOF in the middle the XML
> response, then I'm not surprised by that error.
[...]
> The Subversion client has been dealing with chunked encoding since its
> inception back in 2000. The Apache httpd server (and mod_dav(_svn))
> have been sending responses that way forever. I really can't see that
> this is a problem on the client side.
Scratch that. It seems that this is a grave problem in yet another
(I already had to deactivate one for similar reasons)
dirty "wrapper" class of SvnBridge, ListenerResponse.cs.
Its Flush() _override_ handler (which does get invoked by system-side
handlers directly!) has problematic state handling, with an open-coded
bool "flushed" member.
AND THAT MEMBER NEVER GETS RESET, EVEN IN CASE OF CONTINUED WRITES!
which means the Flush() member reliably prevents any object lifetime cleanup
(via "using", i.e. Dispose() / destructor)
from properly executing these members' Flush() on shutdown.
Wireshark analysis does show that traffic does end right within the
timestamp part, BTW, which does suggest a flushing problem on the sender
side (SvnBridge).
Unfortunately, early attempts at trying to fix that problematic flushing
now initially resulted in even less working transfers (keep hitting timeouts).
Oh well, back to Wireshark analysis (previous semi-working handling vs.
now broken handling).
Possibly it's a matter of intermingled writers writing on the same
output, with now mixed-up flushing happening, or some such.
> Would you mind trying the same scenario using ra_serf? It doesn't have
> any problems with chunked responses either, but it might give a
> different error which would help direct some further inquiry.
Originally I thought that it's not needed any more,
but now that I'm hitting further issues it might turn out to be helpful.
Thank you for your very detailed reply!
Andreas Mohr
Received on 2012-05-11 13:39:58 CEST