Hello Oleg and others,
Suppose I have the following basic code structure:
Init() {
// Create a new MultiThreadHTTPConnectionManager if one does not
exist()
// Create an HTTPClient if one does not exist()
}
HandleRequest() {
// Create new method
try{
// Execute the method, without Connection:Close set
}
catch (IOException e) {
// WANT TO CLOSE THE CONNECTION, because of the error
}
catch (HTTPException h) {
// WANT TO CLOSE THE CONNECTION, because of the error
}
finally {
method.releaseConnection();
}
Where I say WANT TO CLOSE THE CONNECTION, would the following suffice?
method.setConnectionCloseForced();
method.responseBodyConsumed();
Thanks or your guidance,
Vivek
-----Original Message-----
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 14, 2005 4:17 AM
To: [email protected]
Subject: Re: Flushing the response upon IO error
On Tue, Dec 13, 2005 at 02:31:37PM -0500, Satsangi, Vivek wrote:
> We are using http-client inside a servlet running on the SUNOne
> webserver, JVm version 1.4.2_06. The servlet acts like a reverse proxy
> for a web-exposed application.
>
> One user can only access the http client connection object once at a
> time. For this reason, I thought that we don't need to use the
> multi-threaded connection manager. However, we see some errors where
the
> contents of the wire are "mangled" -- e.g. the http status line is not
> found, partial http, etc.
>
> Question 1. Does the connection manager have some sort of class-level
> statics that are used to maintain the list of connections so that even
> though the users' sessions should not be able to "see" each others'
> connection objects, somehow the connection object are ending up
getting
> shared?
>
> We occasionally get some sort of I/O error when trying to do an https
> connection to the back end. Once a connection gets such an error, the
> error "stays", so that subsequent connections will not find the HTTP
in
> the status line, etc. Because of this, I switched to using http
instead,
> and setting the Connection: close header. This would cause fairly bad
> performance if we were using https, obviously.
>
> Question 2: Suppose I get an IO error when executing the method. Is
> there a way to tell the connection manager to close *this* connection
> (and create new ones as necessary) so that the error at least does not
> "propogate"? Alternately, can I somehow flush the response object /
> response body stream so that the next connection will be "fresh"?
>
>
> Thanks for any guidance you are able to give me.
>
Vivek,
HTTP connection managers are not aware of the concept of a user or a
user session. HTTP connection managers assign connections based on the
combination of the following attributes: host name, port, local address,
proxy host, proxy port.
If your application executes HTTP methods from multiple threads using
the same connection manager / HttpClient instance, you MUST ensure that
access to the underlying HTTP connection objects is synchronized
The simple connection manager used by HttpClient per default is NOT
threading-safe. This pretty much explains the problems you are seeing.
Consider using the multithreaded connection manager instead
Hope this helps
Oleg
> Vivek Satsangi
---------------------------------------------------------------------
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]
