W3C home > Mailing lists > Public > www-lib@w3.org > April to June 2000

Re: libwww pipelining bug?

From: <Jose.Kahan@inrialpes.fr>
Date: Wed, 14 Jun 100 17:31:33 +0200 (MET DST)
Message-Id: <200006141531.RAA11312@tuvalu.inrialpes.fr>
To: mgrouch@usa.net (Mikhail Grouchinski)
Cc: www-lib@w3.org
A bit late ... as is the current trend this week!

Hello Mikhail,

In our previous episode, Mikhail Grouchinski said:
> It seems the problems with pipelining in libwww (sometimes requests to
> the same host get stuck in libwww) relate to incorrect handling
> EPIPE, ECONNRESET in HTWriter_write.
> I noticed significant difference in HTWriter and HTReader for handling

Good analysis. According to my Network Programmer's Manual and the on-line
man doc, ECONNRESET is not generated when writing to a socket. So, it seems
normal that there's no procedure to deal with it in HTWriter.

However, I had also seen that even if the connection is broken, libwww
continues writing to a socket. I've added a simplified version of your
patch to HTWriter, which does the same thing you proposed, and I'm going
to test it with Amaya, to see if we see some improvements, or at least no
drawbacks :)

I think that the best solution, however, would be to modify a bit the HTTP.c
module so that it does take into account the writes. Your explanation allowed
me to see that the write behavior I had been observing came because the
status code is only checked AFTER posting whatever should be sent, sone
lines afterwards in the function. This should affect POSTS, and maybe PUTS

I'll continue testing this before commiting the patch, as I'm not quite sure
that it was the best solution. If the libwww community wants to test the
patch as it is, I can commit, though :)

Maybe you have seen some other things since the time you sent your patch?



> I also attach Olga's previous reply
> Is that the requests are not failing but hanging unhandled in pipeline?
> Trace may help. I used the plocking sockets and in some cases if one request
> fails then all the subsequent requests to the same host would fail. I
> (partially) fixed the problem returning HT_CLOSED instead of HT_ERROR from
> HTWriter_write on broken pipe error. Also if you can stop in debugger in
> HTWriter_write at the line where broken pipe is handled and look at the stack
> - you can see that several functions do not check the return value of
> HTWriter_write and just continue (to write on closed socket). That happens in
> HTTPReq.c an d HTTPGen.c. In most cases the HT_CLOSED return will be
> eventually
> checked in consecutive writes (and HTHost_recoverPipe be called later) but
> not
> in all.
> All that maybe does not have anything in common with your problem, but who
> knows :-) ...
Received on Wednesday, 14 June 2000 11:31:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:52 UTC