Hi Srinivas,
Yes, that's what we did here, afterwards the connections that were
previously held open, were closed.
Sorry if it wasn't clearer in my first email.
Cheers,
Marcus
On Mon, Feb 02, 2004 at 05:31:33PM +0530, Srinivas Vemula wrote:
Thanks Marcus,
Are u saying we should add getMethod.addRequestHeader(Connection,
close) for every request made using HttpClient ? Excuse me if I
missed your point completely.
srini
Marcus Crafter wrote:
Hi Srinivas, et al,
Hope all is well.
We've also experienced a similar story here in Oz just the other day.
Essentially connections to the webserver were not being released and were
consuming sockets on the client (determined via OptimizeIT).
After searching the dev list I found a post by another developer that said
this was the default behaviour for HTTP 1.1 which HttpClient honoured (ie.
keep-alive), if the server didn't indicate what the client should do with
the connection.
When I looked into the headers via a wire trace I saw that indeed the
server (IIS in this case) didn't send a 'Connection: close' header and
after browsing the HttpClient source saw that the connection was kept
alive if using HTTP 1.1.
The non-programatic way to fix it was to add a request header to each
client request saying 'Connection: close'.
After doing this, HttpClient closed all connections after they were
released and the open socket problem went away.
Hope this helps.
Cheers,
Marcus
On Mon, Feb 02, 2004 at 04:26:39PM +0530, Srinivas Vemula wrote:
Oleg,
We are using JDK1.4.1 and connection time out is set to 30Ms and
read time out to 60Ms. We are trying to connect to a IP Camera, and send
a heart beat command to the camera to check for its availability every
30 Secs from the time we find it is un available. If the web server is
down, we feel that HttpClient is not cleaning up failed connections
properly and thats resulting in Memory Leaks at the server side.
The code we use is the standard way of using HttpClient and all the
code is in a method and new HttpClient object is created for every
request. Are there any ways to make sure the connections are all being
purged properly? Are there any precautionary measures or flags we can
set on HttpClient API when communicating with a web server (running on
firm ware) with relatively less RAM and processing power (IpCamera with
built in web server)?
Thanks for your time and help.
Srini
Kalnichevski, Oleg wrote:
Mike and Oleg, the stack trace Srini included indicates that HttpClient
is
attempting to create a new timeout thread on every connection - does
this
always occur or is it just one timeout thread per httpclient instance?
It
would be ideal if we could reduce this to one static thread as starting
threads is never nice for server side apps. Not sure how feasible that
is
though.
Hi Srini,
HttpClient uses an additional controller thread to work around the
limitation of older ( 1.4) JDKs which do not provide a possibility to
set connect timeout. If you do not really need to control connect
timeout (for instance, when communicating with an intranet site with
good availability) simply set connect timeout to. That will prevent
HttpClient from spawning an additional thread per request.
Adrian, et al
Another possibility to use reflection to set connect timeout using the
Socket methods when running in JVM 1.4 or above
Oleg
-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 09:03
To: Commons HttpClient Project
Subject: Re: Memory Leaks when web server hangs
On 2/2/04 2:00 PM, Srinivas Vemula [EMAIL PROTECTED]
wrote:
Hi All,
We are seeing thread leaks when having client open connections to a
web
server that hangs. Has any one seen this happening?? How do we ensure
that the
library correctly closes socket connections on failures, cleaning up
system
resources, and threads actually finish in the timeout period and get
freed
up. Would using MultiThreadedHttpConnectionManager
file:///D:/silkroad/http-commons/commons-httpclient-2.0-rc3/docs/threading.ht
ml#MultiThreadedHttpConnectionManager be of any help??
Hi Srini,
If you're using the same HttpClient instance across multiple threads, you
must use the MultiThreadedHttpConnectionManager or you'll run into
strange
problems. If you're using separate HttpClient instances, you may as well
stick with the single threaded (default) connection manager.
In terms of connections hanging - you probably want to look into the
setConnectionTimeout and setTimeout methods of the HttpClient class.
These
allow you to control how long HttpClient waits when making a connection
and
how long it waits for data once the connection is established. If you
have
set either of these to 0 (not sure what the default
