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 { client.execute(method) s = method.getResponseAsStream try { processStream(s) } catch(MyException) { method.abort(); } } finally { method.releaseConnection(); }
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
