Flushing the response upon IO error

["Satsangi, Vivek " <Vi...@xerox.com>]

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 Satsangi

Re: Flushing the response upon IO error

[Oleg Kalnichevski <ol...@apache.org>]

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: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org