You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Kate Rhodes <kr...@virage.com> on 2003/07/10 17:50:30 UTC
Connections not closing bug
we have a situation where our connections just aren't closing
HttpMethodBase.ensureConnectionRelease() is getting called
however when it calls
responseConnection.releaseConnection();
the httpConnectionManager refered to inthat manager is == null and thus the
method only serves to set used = true;
and doesn't actually close the connection.
our current workaround is adding a
responseConnection.close(); after the
responseConnection.releaseConnection(); line in ensureConnectionRelease()
Is this a bug or are we somehow not implementing things incorrectly?
Related note: having public access to that connection object would have
save us sooo
many headaches. I understand that you *shouldn't* ever need to get it..but
when you
do the impossibility of its retrieval is really frustrating. Or maybe you
can get it
and I just can't figure out how
the following code is used to set up the initial connection that is not
closing. No exceptions are being thrown. Everything appears to work fine
except for the connections not closing. To add to the problem. SOME of them
close on their own (without our patch) but not all. We're not sure what the
difference between the ones that do and don't is.
HttpClient client = new HttpClient();
client.setConnectionTimeout(timeout_);
client.setTimeout(timeout_);
URL url = new URL("http", hostname_, port_, "");
PostMethod urlPost = new PostMethod(url.toString());
urlPost.setRequestBody(xmlCommand);
urlPost.addRequestHeader("Content-Type",
"application/x-www-form-urlencoded; charset=UTF-8");
urlPost.addRequestHeader("Accept-Charset", "utf-8");
urlPost.addRequestHeader("User-Agent", "ATG Java");
urlPost.setStrictMode(false);
try {
responseCode_ = client.executeMethod(urlPost);
response_ = new String(urlPost.getResponseBody(), "UTF-8");
} catch (HttpException e) {
System.out.println(client.getState().toString());
urlPost.releaseConnection();
throw e;
}
-------------------------------------------------
Kate Rhodes
Virage Advanced Technology Group
600 Unicorn Park Drive
Woburn, MA 01801-3343
Tel: 781.938.9763
FAX: 781.938.9765
GnuPG / PGP: A324 5092 B12A 41A3 599C A867 C84A F6FA 4B2B 21E6
also 0x4B2B21E6 @ pgp.mit.edu
-------------------------------------------------
Re: Connections not closing bug
Posted by Michael Becke <be...@u.washington.edu>.
Hello from Boston Kate!
In general, HttpMethodBase and the two connection managers try to reuse
connections as much as possible. This is purely for performance
purposes. Part of the HTTP spec defines when connections should be left
open and when they should be closed (see
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8> for more
detail). HttpClient tries its best to honor the contract. The best way
to ensure that a connection is not reused is to set the Connection
header to "close". You can do this with:
HttpMethod.addRequestHeader("Connection", "close");
Mike
Kate Rhodes wrote:
> we have a situation where our connections just aren't closing
> HttpMethodBase.ensureConnectionRelease() is getting called
> however when it calls
> responseConnection.releaseConnection();
> the httpConnectionManager refered to inthat manager is == null and thus the
> method only serves to set used = true;
> and doesn't actually close the connection.
>
> our current workaround is adding a
> responseConnection.close(); after the
> responseConnection.releaseConnection(); line in ensureConnectionRelease()
>
> Is this a bug or are we somehow not implementing things incorrectly?
>
> Related note: having public access to that connection object would have
> save us sooo
> many headaches. I understand that you *shouldn't* ever need to get it..but
> when you
> do the impossibility of its retrieval is really frustrating. Or maybe you
> can get it
> and I just can't figure out how
>
>
>
>
> the following code is used to set up the initial connection that is not
> closing. No exceptions are being thrown. Everything appears to work fine
> except for the connections not closing. To add to the problem. SOME of them
> close on their own (without our patch) but not all. We're not sure what the
> difference between the ones that do and don't is.
>
>
>
> HttpClient client = new HttpClient();
> client.setConnectionTimeout(timeout_);
> client.setTimeout(timeout_);
>
> URL url = new URL("http", hostname_, port_, "");
>
> PostMethod urlPost = new PostMethod(url.toString());
> urlPost.setRequestBody(xmlCommand);
> urlPost.addRequestHeader("Content-Type",
> "application/x-www-form-urlencoded; charset=UTF-8");
> urlPost.addRequestHeader("Accept-Charset", "utf-8");
> urlPost.addRequestHeader("User-Agent", "ATG Java");
> urlPost.setStrictMode(false);
>
>
>
> try {
> responseCode_ = client.executeMethod(urlPost);
>
> response_ = new String(urlPost.getResponseBody(), "UTF-8");
> } catch (HttpException e) {
> System.out.println(client.getState().toString());
> urlPost.releaseConnection();
> throw e;
> }
>
>
> -------------------------------------------------
> Kate Rhodes
> Virage Advanced Technology Group
> 600 Unicorn Park Drive
> Woburn, MA 01801-3343
> Tel: 781.938.9763
> FAX: 781.938.9765
> GnuPG / PGP: A324 5092 B12A 41A3 599C A867 C84A F6FA 4B2B 21E6
> also 0x4B2B21E6 @ pgp.mit.edu
> -------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>