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]

Reply via email to