hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Gl├╝ck <ortwin.glu...@nose.ch>
Subject Re: threads problem with many connections
Date Fri, 01 Oct 2004 13:46:09 GMT

Guillaume Cottenceau wrote:
> If, for example, the HTTP server sends one "a" byte once per
> second forever, HttpClient will never exit from executeMethod -
> if I'm correct.

Yes. It's up to you to decide if that sort of communication makes sense. 
HTTP allows it however.

>>2. Open connections
>>You can set timeouts for idle connections, so you will get a timeout
>>exception after a while. If the connection is active (i.e. client is
> Yes, but that's out of the scope of the described problem.

Sorry if I am missing the point!?

>>receiving data), your application should be able to figure out if it
>>is legitimate to stay open for such a long time and otherwise just
>>abort the method.
> There's no such thing available in HttpClient, as far as I know?

What 'thing'? Abort? see HttpMethod#abort in 3.0

> This needs a monitor Thread setting a timeout in our application.

You call
try {
  s = method.getResponseAsStream
  try {
  } catch(MyException) {
} finally {

Inside your stream processing you are free to throw an exception.

> It could make sense to implement this timeout in HttpClient, as
> I've said in previous mail, however I am not sure it is "allowed"
> by the HTTP protocol.

No it doesn't. HttpClient doesn't care what you send over the wire, and 
it does not care how fast you are doing this either, because HTTP does 
not specify that of course. Your problem is completely in the 
application domain and not in the protocol domain.

To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message