Thank you for sending your sample code. It has been quite helpful.
I have discovered a few interesting things. I have been able to reproduce something similar to what you have been describing. It seems that in JRE 1.2.2 and 1.3.1 (not 1.4.1) that when a connection is closed on the server side (due to inactivity) writing to it causes and IOException (in 1.4.1 it is a SocketException). This is important because SocketExceptions are considered recoverable where IOExceptions are not. So this error will not show up on some JREs as it will get treated as a recoverable exception and will be handed by the HttpMethod.
This brings up a few questions:
1) should we de differentiating between SocketExceptions and IOExceptions?
2) is there some other more reliable way to determine if a connection is closed?
Also, this error points out a bug in HttpConnection. When an IOException occurs on a connection the method fails but the connection is never closed or marked as unusable. Therefore is keeps getting reused even though it will always throw an IOException. This is not a problem in the case of SocketExceptions as the connection gets reopened by the method. It seems to me that the HttpConnection should probably be closing itself when any exception occurs during writing (maybe reading too). What do others think?
Sergio. To fix this problem for the short term I would suggest either using HTTP 1.0 or a JRE that does not exhibit this problem. Using HTTP 1.0 will cause the connections to not be reused (call HttpMethod.setHttp11(false) ). Using a 1.4.1 (at least for me) will cause recoverable exceptions that will get handed by the method.
Any other thoughts on this would be appreciated.
Thanks,
Mike
On Wednesday, March 26, 2003, at 02:11 PM, Sergio Berna wrote:
I have been trying to build a small piece of code that could reproduce this bug, the problem is that im executing this inside a weblogic server and i have not been able to reproduce the same behavior on the client.
At the client i find the "cant read HTTP/ message" after some time on second connection(over 15 seconds) but retrying does work. At the server it is the "broken pipe one" and no matter the amount or times i retry it is always the same message.
As soon is as i have a working class able to reproduce the error ill send it, meanwhile im attaching the class im using in case im doing something stupid and havent realized.
Thanks for your time.
Sergio.
-----Mensaje original----- De: Michael Becke [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 26 de marzo de 2003 19:09 Para: Commons HttpClient Project Asunto: Re: connections on pool close unexpectedly
I do not think this is the problem Sergio is having. He seems to be having problems with connections becoming unusable, not having to many open connections. We shall see though.
Sergio, please let us know when you have more details so we can help you
get to the bottom of this.
Thanks,
Mike
Carl A. Dunham wrote:
> Sergio,
>
> I had posted a crude patch a few days ago that partially solves this problem.
> It basically adds a wider connection pool that tracks free connections,
> closing them when needed and blocking requests in order to maintain a maximum
> number of open connections.
>
> It is better, but still not quite right. Maybe it'll help you...
>
> BTW, I'm not an httpclient developer, just a user trying to solve my own
> problems...
>
> Carl
>
>
> On Tuesday March 25 2003 12:45, Sergio Berna wrote:
>
>>Just one more question then, before ill try to correct it myself, im
>>assuming that the connections are been pooled inside the multhreadedmanager
>>so as to improve performance.
>>
>>The only problem im facing is that the manager doesnt realize the
>>connection is broken and i cant find any method to tell it, so the
>>connection is forever broken at the pool and no matter the attemps i do it
>>is always used first with the expected failure.
>>
>>Is there any method to expire the connection fotever or should i always
>>create a new HttpClient so that i can use a new pool?
>>
>>If it doesnt i could try solving this problem by automatically deleting a
>>connection which had thrown an IOException (then a reconnect would work) or
>>making a method to expunge it out of the pool. The last one is tricky since
>>you cant use it with the responsebody methods.
>>
>>Which one do you suggest?
>>
>>Sergio.
>>
>>
>>
>>-----Mensaje original-----
>>De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
>>Enviado el: martes, 25 de marzo de 2003 18:36
>>Para: Commons HttpClient Project
>>Asunto: Re: connections on pool close unexpectedly
>>
>>
>>Sergio
>>
>>I regret that your message has been left unanswered for so long. The
>>problem is that out of 4 committers I seem to be the only one currently
>>monitoring this forum on a regular basis, and I just happened to not be
>>using connection pooling much. So, I am not the best source to turn to
>>in this regard. You'll have to wait until Mike gets back in order to get
>>a more informed opinion on your problem.
>>
>>However, that little can can tell:
>>
>>Both HTTP server and HTTP client may close connection at any time
>>according to the HTTP spec. I suppose that the HTTP server you are using
>>may be dripping connections after a minute of inactivity. This is a
>>perfectly standard compliant behavior. I am afraid you might have to
>>live with it and simply try the request after having caught a retriable
>>exception
>>
>>I would help you provided us with more detailed information on the setup
>>you are using
>>
>>Cheers
>>
>>Oleg
>>
>>On Fri, 2003-03-21 at 14:13, Sergio Berna wrote:
>>
>>>Hello,
>>>
>>>I am having problems with HttpClient 2.0-alpha3 when i try to pool it.
>>>
>>>After the first call to stablish a connection against a server i usually
>>
>>can
>>
>>
>>>work with the client for 1 minue requetsing new pages. But after that
>>
>>minute
>>
>>
>>>i think the connecion is been closed somehow because any new attempt to
>>>retrieve any file at the host is rejcted instantly with the message
>>>BrokenPipe.
>>>
>>>Afetr logging it the problem arises just after the first attemt to write
>>
>>the
>>
>>
>>>HTTP header for the request so i suppose it is closed somehow either by
>>
>>the
>>
>>
>>>client or the server and the client always attemps to write to the same
>>>stream.
>>>
>>>Thanks for your time.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail:
>>[EMAIL PROTECTED]
>>For additional commands, e-mail:
>>[EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
