You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Juan Pedro López Sáez <jp...@altiria.com> on 2005/03/30 10:52:42 UTC
connectionManager.releaseConnection()
Hi all.
AFAIK the best way to ensure the underlying socket of a connection is
actually closed is overiding the connectionManager.releaseConnection()
method to do the job.
In my case I am using the multithreaded connection manager and after
inspecting the code I'm not sure about what I should do to get this
behaviour without breaking anything.
Could anybody give any hint on this matter?
I guess that after succesfully overriding the
connetionManager.releaseConnection() method, every call to
method.releaseConnection() will indirectly do the job. I have seen the
code but this is not clear enough for me.
Thank you very much.
--
Juan Pedro López Sáez
ALTIRIA TIC, Soluciones en Servicios Móviles
Tlf: 913 311 198
Móvil: 610 258 837
www.altiria.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: connectionManager.releaseConnection()
Posted by Ortwin Glück <or...@nose.ch>.
Juan Pedro López Sáez wrote:
> Hi Ortwin.
>
> As you say it should be probably worth providing a multithreaded
> non-pooling connection manager with the HttpClient dist.
>
> Right now I think I am not able to implement a new Connection manager to
> fit my needs. I guess that after some effort inspecting the source code
> I could develop my own class with success. The problem is I don't have
> enough time to do it, so I would like to find an intermediate solution.
>
> I'm thinking about using the "Connection: close" header in my request,
> but some questions arise:
>
> - Can I trust in this mechanism to have HttpClient close every
> connection after calling method.releaseConnection()?
>
> - If this is not completely true, in what situations will this header
> do the job? What are the main drawbacks of this solution?
>
> Thank you for your help.
You can try and use Connection: close. It should yield the same results,
but of course is dependent on a standards compliant server. Real-world
servers may completely ignore your request to close the connection.
You should give your own connection manager at least a try. I figure it
won't be more than a screen full of simplistic Java code.
However there are some drawbacks. They are the same whether you decide
to use Connection: close or a non-pooling connection manager. You will
run into problems whenever a connection needs to be retried and state
must be kept on that connection between retries. That is with all
stateful authentication schemes like Digest and NTLM. Basic should work
okay however. Also POST requests might have problems when using
100-continue handshake. I have never tested that, though.
Still, if you can, don't get rid of pooling, because it's one of the
essential features of HTTP/1.1
Ortwin Glück
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: connectionManager.releaseConnection()
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Juan,
> Right now I think I am not able to implement a new Connection manager to
> fit my needs. I guess that after some effort inspecting the source code
> I could develop my own class with success. The problem is I don't have
> enough time to do it, so I would like to find an intermediate solution.
Try something like this:
class NoReuseConnectionManager extends MultiThreadedConnectionManager {
releaseConnection(HttpConnection conn) {
conn.close()
super.releaseConnection(conn)
}
}
hope that helps,
Roland
Re: connectionManager.releaseConnection()
Posted by Juan Pedro López Sáez <jp...@altiria.com>.
Hi Ortwin.
As you say it should be probably worth providing a multithreaded
non-pooling connection manager with the HttpClient dist.
Right now I think I am not able to implement a new Connection manager to
fit my needs. I guess that after some effort inspecting the source code
I could develop my own class with success. The problem is I don't have
enough time to do it, so I would like to find an intermediate solution.
I'm thinking about using the "Connection: close" header in my request,
but some questions arise:
- Can I trust in this mechanism to have HttpClient close every
connection after calling method.releaseConnection()?
- If this is not completely true, in what situations will this header
do the job? What are the main drawbacks of this solution?
Thank you for your help.
> Juan,
>
> while this completely defeats the purpose of the HTTP keep-alive
> feature, I understand that there are special situations when one needs
> what you describe. That means you can do away with the connection
> pooling altogether. It also means that none of the existing
> ConnectionManager implementatinos suite your needs. You had better
> implementing a completely new ConnectionManager that does not attempt to
> pool a connection but every call to getConnection just creates a new one
> and every call to releaseConnection just closes it. This should be very
> easy to do. Maybe we should provide such a simple non-pooling connection
> manager with the stock version of HttpClient.
>
--
Juan Pedro López Sáez
ALTIRIA TIC, Soluciones en Servicios Móviles
Tlf: 913 311 198
Móvil: 610 258 837
www.altiria.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: connectionManager.releaseConnection()
Posted by Ortwin Glück <or...@nose.ch>.
Juan,
while this completely defeats the purpose of the HTTP keep-alive
feature, I understand that there are special situations when one needs
what you describe. That means you can do away with the connection
pooling altogether. It also means that none of the existing
ConnectionManager implementatinos suite your needs. You had better
implementing a completely new ConnectionManager that does not attempt to
pool a connection but every call to getConnection just creates a new one
and every call to releaseConnection just closes it. This should be very
easy to do. Maybe we should provide such a simple non-pooling connection
manager with the stock version of HttpClient.
Ortwin Glück
Juan Pedro López Sáez wrote:
> Hi Ortwin,
>
> Actually I'm not experiencing any problem with HttpClient but just want
> to be sure that every connection is really closed and not reused after
> calling method.releaseConnection().
>
> I'm developing a critical component based on HttpClient to handle lots
> of HTTP connections to different servers and I want it to close every
> HTTP connection.
>
> Watching some threads I could see that the best way to achieve this
> behaviour is overriding connectionManager.releaseConnection() but I
> don't know how to do it properly.
>
> Is there any other option to satisfy my needs?
>
> Thank you very much.
>
> Juan Pedro
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: connectionManager.releaseConnection()
Posted by Juan Pedro López Sáez <jp...@altiria.com>.
Hi Ortwin,
Actually I'm not experiencing any problem with HttpClient but just want
to be sure that every connection is really closed and not reused after
calling method.releaseConnection().
I'm developing a critical component based on HttpClient to handle lots
of HTTP connections to different servers and I want it to close every
HTTP connection.
Watching some threads I could see that the best way to achieve this
behaviour is overriding connectionManager.releaseConnection() but I
don't know how to do it properly.
Is there any other option to satisfy my needs?
Thank you very much.
Juan Pedro
>
> Juan,
>
> The connection manager handles connections for you. It should not be
> necessary to deal with connections directly. It should not matter to you
> if a connection is new or a reused one. Why would you want to override
> releaseConnection()? What is the problem you are experiencing that makes
> you think you would have to change the standard behaviour of HttpClient?
>
> Ortwin Glück
-
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: connectionManager.releaseConnection()
Posted by Ortwin Glück <or...@nose.ch>.
Juan Pedro López Sáez wrote:
> Hi all.
>
> AFAIK the best way to ensure the underlying socket of a connection is
> actually closed is overiding the connectionManager.releaseConnection()
> method to do the job.
Juan,
The connection manager handles connections for you. It should not be
necessary to deal with connections directly. It should not matter to you
if a connection is new or a reused one. Why would you want to override
releaseConnection()? What is the problem you are experiencing that makes
you think you would have to change the standard behaviour of HttpClient?
Ortwin Glück
--
_________________________________________________________________
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer
hardturmstrasse 171 [pgp id] 0x81CF3416
8005 zürich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org