You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Om Narayan <om...@hotmail.com> on 2003/06/05 21:59:14 UTC
Questions related to the use of HttpClient classes
Please validate my understanding of how HttpClient and the other classes
work together.
1. When I do "httpclient = new HttpClient", the object is created by default
with the SimpleHttpConnectionManager.
2. I create "post = new PostMethod(url)" and call
httpclient.executeMethod(post). At this point httpclient takes the url in
the post object and using the SimpleHttpConnectionManager, creates a
HttpConnection object. This connection is retained by the
SimpleHttpConnectionManager and (possibly?) reused.
3. After connection is established, data is posted, and the result
retrieved.
4. I do post.releaseConnection(). Does the connection get closed at this
point? Is the HttpConnection object still around? What do I need to do if I
had wanted to have the connection stay alive (because it takes time to
re-establish the connection)?
5. Is post.recycle() related to connection in any way? What is the purpose
of this? Is PostMethod ctor an expensive operation?
6. SimpleHttpConnectionManager doc says "This manager makes no attempt to
provide exclusive access to the contained HttpConnection". Does this mean
that calling httpclient.execute() method in this case is not thread-safe?
7. If I wanted to use "connection pooling" should I be using
MultiThreadedHttpConnectionManager instead? Or do I need to implement my
own pooling?
I am sure I have other questions, but this will do for now. :)
Thanks.
Om.
Re: Questions related to the use of HttpClient classes
Posted by Eric Johnson <er...@tibco.com>.
Om,
Responses follow....
Om Narayan wrote:
>Please validate my understanding of how HttpClient and the other classes
>work together.
>
>1. When I do "httpclient = new HttpClient", the object is created by default
>with the SimpleHttpConnectionManager.
>2. I create "post = new PostMethod(url)" and call
>httpclient.executeMethod(post). At this point httpclient takes the url in
>the post object and using the SimpleHttpConnectionManager, creates a
>HttpConnection object. This connection is retained by the
>SimpleHttpConnectionManager and (possibly?) reused.
>
The connection will be reused if you invoke another request that uses
the "Simple" connection manager.
>3. After connection is established, data is posted, and the result
>retrieved.
>4. I do post.releaseConnection(). Does the connection get closed at this
>point? Is the HttpConnection object still around? What do I need to do if I
>had wanted to have the connection stay alive (because it takes time to
>re-establish the connection)?
>
"releasing" a connection should not be confused with "closing" the
connection. "Releasing" ensures that it can be safely reused by a
subsequent request. For the most part, releasing a connection is
entirely unnecessary with the "SimpleHttpConnectionManager", as it only
has one connection, and it will "release" it internally before handing
it out for a subsequent request. Closing a connection only happens when
necessary - as in a "Connection: close" header, an Http 1.0 response, or
any of the other various standard reasons for forcing a connection
closed. As a general rule of thumb, HttpClient only closes the
underlying socket connection when absolutely necessary (unless you are
using HTTPS and a proxy server, as I recall).
>5. Is post.recycle() related to connection in any way? What is the purpose
>of this? Is PostMethod ctor an expensive operation?
>
>
I think that previous discussion on the "recycle" operation has
indicated to me that this is a largely spurious function. It might be
useful, but I suspect it is mostly premature optimization. The code in
our application simply makes a new "Method" object for each new
request. Of course, we don't make millions of requests, which others
might be, and they might report differently.
>6. SimpleHttpConnectionManager doc says "This manager makes no attempt to
>provide exclusive access to the contained HttpConnection". Does this mean
>that calling httpclient.execute() method in this case is not thread-safe?
>
>
As soon as you do an "execute" on the next method using the
SimpleHttpConnectionManager, the previous response data becomes
invalid. In this sense, it is not even "single thread" safe. For
example, code written like this: execute A, execute B, read A, read B
will fail on the attempt to read A. Used across multiple threads, even
worse things can happen. I recommend using
MultiThreadedHttpConnectionManager.
>7. If I wanted to use "connection pooling" should I be using
>MultiThreadedHttpConnectionManager instead? Or do I need to implement my
>own pooling?
>
It should be sufficient to use the MultiThreadedHttpConnectionManager,
which actually serves multiple tasks, one of them being pooling.
>
>I am sure I have other questions, but this will do for now. :)
>Thanks.
>
>Om.
>
Good luck.
-Eric Johnson
Re: Questions related to the use of HttpClient classes
Posted by Ortwin Glück <or...@nose.ch>.
Manuel Castro Paliza wrote:
> So finally the cuestion is :
> is a Pool of Methods also a High-Level pool of Connections when not using
> MultiThreadedHttpConnectionManager ?
No. A method requests a connection from the connection manager on
demand. There is no fix association between a method and a connection.
Re: Questions related to the use of HttpClient classes
Posted by Michael Becke <be...@u.washington.edu>.
> Yes, but recommendation says 2-3 connections per host/server..
> and I don't know the number of simultaneous connections, nor the peak,
> what about changing it at runtime?.
Yes, this is the recommend number according to the RFC. But, depending
on your application, it may make sense to change this. Changing this
value at runtime is probably not the best idea but it should work.
> finally I did a HttpClientPool with singleton
> SimpleHttpConnectionManager
> with a Factory but I'm not sure if the SimpleHttpConnectionManager can
> actually be Singleton or not.
>
> //private MultiThreadedHttpConnectionManager mtcm = null;
> private SimpleHttpConnectionManager stcm=null;
> protected HttpClientFactory() {
> // mtcm = new MultiThreadedHttpConnectionManager();
> stcm= new SimpleHttpConnectionManager();
> }
> public Object newInstance() {
> log.debug("Creation of a new Client!");
> return new HttpClient(stcm/*this.mtcm*/);
> }
>
You definitely do not want to share an instance of
SimpleHttpConnectionManager. It only has a single connection and will
give it to any code that asks for it, regardless of if it's already
being used.
Mike
RE: Questions related to the use of HttpClient classes
Posted by Manuel Castro Paliza <mc...@tid.es>.
Yes, but recommendation says 2-3 connections per host/server..
and I don't know the number of simultaneous connections, nor the peak,
what about changing it at runtime?.
finally I did a HttpClientPool with singleton SimpleHttpConnectionManager
with a Factory but I'm not sure if the SimpleHttpConnectionManager can
actually be Singleton or not.
//private MultiThreadedHttpConnectionManager mtcm = null;
private SimpleHttpConnectionManager stcm=null;
protected HttpClientFactory() {
// mtcm = new MultiThreadedHttpConnectionManager();
stcm= new SimpleHttpConnectionManager();
}
public Object newInstance() {
log.debug("Creation of a new Client!");
return new HttpClient(stcm/*this.mtcm*/);
}
Thanks!.
-----Mensaje original-----
De: Michael Becke [mailto:becke@u.washington.edu]
Enviado el: viernes, 06 de junio de 2003 14:12
Para: Commons HttpClient Project
Asunto: Re: Questions related to the use of HttpClient classes
> One question More.
> I'm working on a kind of proxy,
> I have ( a lot of ) different users connecting to different servers
> MultiThreadedHttpConnectionManager its not an option because each user
> will
> do one request each time, and something like new HttpClient(MySingleton
> Instance of MultiThreadedHttpConnectionManager ) limits the maximum
> number
> of connections to a host.
Connections per host is configurable if that helps. see
MultiThreadedHttpConnectionManager.setMaxConnectionsPerHost().
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
Re: Questions related to the use of HttpClient classes
Posted by Michael Becke <be...@u.washington.edu>.
> One question More.
> I'm working on a kind of proxy,
> I have ( a lot of ) different users connecting to different servers
> MultiThreadedHttpConnectionManager its not an option because each user
> will
> do one request each time, and something like new HttpClient(MySingleton
> Instance of MultiThreadedHttpConnectionManager ) limits the maximum
> number
> of connections to a host.
Connections per host is configurable if that helps. see
MultiThreadedHttpConnectionManager.setMaxConnectionsPerHost().
Mike
RE: Questions related to the use of HttpClient classes
Posted by Manuel Castro Paliza <mc...@tid.es>.
One question More.
I'm working on a kind of proxy,
I have ( a lot of ) different users connecting to different servers
MultiThreadedHttpConnectionManager its not an option because each user will
do one request each time, and something like new HttpClient(MySingleton
Instance of MultiThreadedHttpConnectionManager ) limits the maximum number
of connections to a host.
I'm using a Pool of Methods but I don't know if this is also a High-Level
pool of Connections.
So finally the cuestion is :
is a Pool of Methods also a High-Level pool of Connections when not using
MultiThreadedHttpConnectionManager ?
Can anybody help me?
Thanks for this useful Component!
Re: Questions related to the use of HttpClient classes
Posted by Ortwin Glück <or...@nose.ch>.
FAQ is good. Improving the API Doc in the spots Om pointed out is even
better.
Odi
Oleg Kalnichevski wrote:
> Mike,
>
> Why do not we indeed make a FAQ document out of this Q & A session with?
>
> Oleg
Re: Questions related to the use of HttpClient classes
Posted by Om Narayan <om...@hotmail.com>.
Thanks for the link--good stuff.
Om.
----- Original Message -----
From: "Mike Moran" <mi...@mac.com>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Friday, June 06, 2003 2:41 AM
Subject: Re: Questions related to the use of HttpClient classes
> Adrian Sutton wrote:
> >
> > On Friday, June 6, 2003, at 08:55 AM, Om Narayan wrote:
> [ ... ]
> >> I have another question to add: How do I "prime" the connections in
the
> >> MultiThreadedHttpConnectionManager pool? I am running into a problem
> >> where
> >> it is taking a long time (almost 30 secs using https) to open the first
> >> connection. As a result the session bean that is opening the
> >> connection is
> >> timing out. I need a way to make the first call to create the
connection
> >> work without timing out. Any suggestion is welcome.
> >
> >
> > I'd say the delay here is actually initialising JSSE rather than
> > actually making the first connection. There should be a way to
> > initialise JSSE without actually making a connection.
> [ ... ]
>
> This might be difficult. I ran in to a problem like this while using a
> JCE implementation. The setup time seems to be caused by Suns
> implementation of SecureRandom. The following thread may be useful:
>
> http://forum.java.sun.com/thread.jsp?thread=4250&forum=2&message=11205
>
> --
> Mike
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: Questions related to the use of HttpClient classes
Posted by Mike Moran <mi...@mac.com>.
Adrian Sutton wrote:
>
> On Friday, June 6, 2003, at 08:55 AM, Om Narayan wrote:
[ ... ]
>> I have another question to add: How do I "prime" the connections in the
>> MultiThreadedHttpConnectionManager pool? I am running into a problem
>> where
>> it is taking a long time (almost 30 secs using https) to open the first
>> connection. As a result the session bean that is opening the
>> connection is
>> timing out. I need a way to make the first call to create the connection
>> work without timing out. Any suggestion is welcome.
>
>
> I'd say the delay here is actually initialising JSSE rather than
> actually making the first connection. There should be a way to
> initialise JSSE without actually making a connection.
[ ... ]
This might be difficult. I ran in to a problem like this while using a
JCE implementation. The setup time seems to be caused by Suns
implementation of SecureRandom. The following thread may be useful:
http://forum.java.sun.com/thread.jsp?thread=4250&forum=2&message=11205
--
Mike
Re: Questions related to the use of HttpClient classes
Posted by Michael Becke <be...@u.washington.edu>.
I agree with Adrian. I think it's the JSSE initialization time. A
long initialization time is common with JSSE in pre 1.4 JVMs. It
should only happen once per JVM or maybe per ClassLoader. As Adrian
suggests you should make some kind of initial HTTPS connection to get
things warmed up.
Mike
On Thursday, June 5, 2003, at 07:18 PM, Adrian Sutton wrote:
>
> On Friday, June 6, 2003, at 08:55 AM, Om Narayan wrote:
>
>> My email had a problem with my last post...so here it goes.
>> Thanks to Mike and Eric, my questions are mostly answered, and I am
>> now able
>> to explain some strange problems that I was seeing. It looks to me
>> that
>> using the MultiThreadedHttpConnectionManager as the default is better
>> as it
>> is less likely to burn some unsuspecting user.
>
> A couple of other things that may or may not be useful to you:
>
> The HttpClient tutorial - it sounds like you've already got the
> fundamentals sorted out, but it's worth reading this quickly anyway.
> http://jakarta.apache.org/commons/httpclient/tutorial.html
>
> And the threading guide:
> http://jakarta.apache.org/commons/httpclient/threading.html
>
> That'll be good for the archives even if you've found those articles
> already.
>
>> I have another question to add: How do I "prime" the connections in
>> the
>> MultiThreadedHttpConnectionManager pool? I am running into a problem
>> where
>> it is taking a long time (almost 30 secs using https) to open the
>> first
>> connection. As a result the session bean that is opening the
>> connection is
>> timing out. I need a way to make the first call to create the
>> connection
>> work without timing out. Any suggestion is welcome.
>
> I'd say the delay here is actually initialising JSSE rather than
> actually making the first connection. There should be a way to
> initialise JSSE without actually making a connection. If not, you may
> find that just doing something like:
>
> try {
> new URL("https://localhost/").openConnection();
> } catch (Exception e) {
> // Log this somewhere but generally ignore it as it's expected to
> fail.
> }
>
> might solve the problem. You would of course want to ensure that the
> timeout is incredibly short (or just do it from a separate thread).
> That would then make sure that JSSE is properly initialized. I'm not
> sure about the exact method of creating a HTTPS connection, you might
> need to copy some code from HttpClient.
>
> The other option if you're always connecting to the same host, is to
> either just execute any method to that host, or request a connection
> from the connection manager then immediately release it again.
>
>> Om.
>
> Mike is King of connection managers though so maybe he'll have some
> better ideas.
>
> Regards,
>
> Adrian Sutton.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
Re: Questions related to the use of HttpClient classes
Posted by Adrian Sutton <ad...@intencha.com>.
On Friday, June 6, 2003, at 08:55 AM, Om Narayan wrote:
> My email had a problem with my last post...so here it goes.
> Thanks to Mike and Eric, my questions are mostly answered, and I am
> now able
> to explain some strange problems that I was seeing. It looks to me that
> using the MultiThreadedHttpConnectionManager as the default is better
> as it
> is less likely to burn some unsuspecting user.
A couple of other things that may or may not be useful to you:
The HttpClient tutorial - it sounds like you've already got the
fundamentals sorted out, but it's worth reading this quickly anyway.
http://jakarta.apache.org/commons/httpclient/tutorial.html
And the threading guide:
http://jakarta.apache.org/commons/httpclient/threading.html
That'll be good for the archives even if you've found those articles
already.
> I have another question to add: How do I "prime" the connections in
> the
> MultiThreadedHttpConnectionManager pool? I am running into a problem
> where
> it is taking a long time (almost 30 secs using https) to open the first
> connection. As a result the session bean that is opening the
> connection is
> timing out. I need a way to make the first call to create the
> connection
> work without timing out. Any suggestion is welcome.
I'd say the delay here is actually initialising JSSE rather than
actually making the first connection. There should be a way to
initialise JSSE without actually making a connection. If not, you may
find that just doing something like:
try {
new URL("https://localhost/").openConnection();
} catch (Exception e) {
// Log this somewhere but generally ignore it as it's expected to fail.
}
might solve the problem. You would of course want to ensure that the
timeout is incredibly short (or just do it from a separate thread).
That would then make sure that JSSE is properly initialized. I'm not
sure about the exact method of creating a HTTPS connection, you might
need to copy some code from HttpClient.
The other option if you're always connecting to the same host, is to
either just execute any method to that host, or request a connection
from the connection manager then immediately release it again.
> Om.
Mike is King of connection managers though so maybe he'll have some
better ideas.
Regards,
Adrian Sutton.
Re: Questions related to the use of HttpClient classes
Posted by Om Narayan <om...@hotmail.com>.
My email had a problem with my last post...so here it goes.
Thanks to Mike and Eric, my questions are mostly answered, and I am now able
to explain some strange problems that I was seeing. It looks to me that
using the MultiThreadedHttpConnectionManager as the default is better as it
is less likely to burn some unsuspecting user.
I have another question to add: How do I "prime" the connections in the
MultiThreadedHttpConnectionManager pool? I am running into a problem where
it is taking a long time (almost 30 secs using https) to open the first
connection. As a result the session bean that is opening the connection is
timing out. I need a way to make the first call to create the connection
work without timing out. Any suggestion is welcome.
Thanks.
Om.
----- Original Message -----
From: "Michael Becke" <be...@u.washington.edu>
To: "Commons HttpClient Project" <co...@jakarta.apache.org>
Sent: Thursday, June 05, 2003 3:25 PM
Subject: Re: Questions related to the use of HttpClient classes
> Quite so. I will get one started. Any other questions you would like
> to see added?
>
> Mike
>
> On Thursday, June 5, 2003, at 04:59 PM, Oleg Kalnichevski wrote:
>
> > Mike,
> >
> > Why do not we indeed make a FAQ document out of this Q & A session
> > with?
> >
> > Oleg
> >
> > On Thu, 2003-06-05 at 22:18, Michael Becke wrote:
> >> Om,
> >>
> >> Nice set of questions. Looks almost like a FAQ :)
> >>
> >>> 1. When I do "httpclient = new HttpClient", the object is created by
> >>> default
> >>> with the SimpleHttpConnectionManager.
> >>
> >> Correct.
> >>
> >>> 2. I create "post = new PostMethod(url)" and call
> >>> httpclient.executeMethod(post). At this point httpclient takes the
> >>> url in
> >>> the post object and using the SimpleHttpConnectionManager, creates a
> >>> HttpConnection object. This connection is retained by the
> >>> SimpleHttpConnectionManager and (possibly?) reused.
> >>
> >> Yes, that's pretty much it. Just to clarify
> >> SimpleHttpConnectionManager
> >> contains a single instance of an HttpConnection and reuses it when
> >> possible. For example if you were to do two GETs from
> >> "http://jakarta.apache.org/" then the connection would be reused.
> >> This
> >> assumes that the server supports connection persistence.
> >>
> >>> 3. After connection is established, data is posted, and the result
> >>> retrieved
> >>> 4. I do post.releaseConnection(). Does the connection get closed at
> >>> this
> >>> point? Is the HttpConnection object still around? What do I need to
> >>> do if I
> >>> had wanted to have the connection stay alive (because it takes time
> >>> to
> >>> re-establish the connection)?
> >>
> >> It depends on the server and a few other variables (like SSL and JVM
> >> version). In general HTTP 1.1 defaults to keep-alive and 1.0 defaults
> >> to close. These defaults can be overriden by the server using the
> >> connection header.
> >>
> >>> 5. Is post.recycle() related to connection in any way? What is the
> >>> purpose
> >>> of this? Is PostMethod ctor an expensive operation?
> >>
> >> It calls releaseConnection() plus some other things. In general I do
> >> not use recycle much. I prefer to create a new instance as it's not
> >> particularly expensive.
> >>
> >>> 6. SimpleHttpConnectionManager doc says "This manager makes no
> >>> attempt to
> >>> provide exclusive access to the contained HttpConnection". Does this
> >>> mean
> >>> that calling httpclient.execute() method in this case is not
> >>> thread-safe?
> >>
> >> Correct. Not thread safe. It would fail quite quickly if used from
> >> multiple threads.
> >>
> >>> 7. If I wanted to use "connection pooling" should I be using
> >>> MultiThreadedHttpConnectionManager instead? Or do I need to
> >>> implement my
> >>> own pooling?
> >>
> >> MultiThreadedHttpConnectionManager is what you want.
> >>
> >> Mike
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> commons-httpclient-dev-help@jakarta.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-httpclient-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: Questions related to the use of HttpClient classes
Posted by Michael Becke <be...@u.washington.edu>.
Quite so. I will get one started. Any other questions you would like
to see added?
Mike
On Thursday, June 5, 2003, at 04:59 PM, Oleg Kalnichevski wrote:
> Mike,
>
> Why do not we indeed make a FAQ document out of this Q & A session
> with?
>
> Oleg
>
> On Thu, 2003-06-05 at 22:18, Michael Becke wrote:
>> Om,
>>
>> Nice set of questions. Looks almost like a FAQ :)
>>
>>> 1. When I do "httpclient = new HttpClient", the object is created by
>>> default
>>> with the SimpleHttpConnectionManager.
>>
>> Correct.
>>
>>> 2. I create "post = new PostMethod(url)" and call
>>> httpclient.executeMethod(post). At this point httpclient takes the
>>> url in
>>> the post object and using the SimpleHttpConnectionManager, creates a
>>> HttpConnection object. This connection is retained by the
>>> SimpleHttpConnectionManager and (possibly?) reused.
>>
>> Yes, that's pretty much it. Just to clarify
>> SimpleHttpConnectionManager
>> contains a single instance of an HttpConnection and reuses it when
>> possible. For example if you were to do two GETs from
>> "http://jakarta.apache.org/" then the connection would be reused.
>> This
>> assumes that the server supports connection persistence.
>>
>>> 3. After connection is established, data is posted, and the result
>>> retrieved
>>> 4. I do post.releaseConnection(). Does the connection get closed at
>>> this
>>> point? Is the HttpConnection object still around? What do I need to
>>> do if I
>>> had wanted to have the connection stay alive (because it takes time
>>> to
>>> re-establish the connection)?
>>
>> It depends on the server and a few other variables (like SSL and JVM
>> version). In general HTTP 1.1 defaults to keep-alive and 1.0 defaults
>> to close. These defaults can be overriden by the server using the
>> connection header.
>>
>>> 5. Is post.recycle() related to connection in any way? What is the
>>> purpose
>>> of this? Is PostMethod ctor an expensive operation?
>>
>> It calls releaseConnection() plus some other things. In general I do
>> not use recycle much. I prefer to create a new instance as it's not
>> particularly expensive.
>>
>>> 6. SimpleHttpConnectionManager doc says "This manager makes no
>>> attempt to
>>> provide exclusive access to the contained HttpConnection". Does this
>>> mean
>>> that calling httpclient.execute() method in this case is not
>>> thread-safe?
>>
>> Correct. Not thread safe. It would fail quite quickly if used from
>> multiple threads.
>>
>>> 7. If I wanted to use "connection pooling" should I be using
>>> MultiThreadedHttpConnectionManager instead? Or do I need to
>>> implement my
>>> own pooling?
>>
>> MultiThreadedHttpConnectionManager is what you want.
>>
>> Mike
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
Re: Questions related to the use of HttpClient classes
Posted by Oleg Kalnichevski <ol...@apache.org>.
Mike,
Why do not we indeed make a FAQ document out of this Q & A session with?
Oleg
On Thu, 2003-06-05 at 22:18, Michael Becke wrote:
> Om,
>
> Nice set of questions. Looks almost like a FAQ :)
>
> > 1. When I do "httpclient = new HttpClient", the object is created by default
> > with the SimpleHttpConnectionManager.
>
> Correct.
>
> > 2. I create "post = new PostMethod(url)" and call
> > httpclient.executeMethod(post). At this point httpclient takes the url in
> > the post object and using the SimpleHttpConnectionManager, creates a
> > HttpConnection object. This connection is retained by the
> > SimpleHttpConnectionManager and (possibly?) reused.
>
> Yes, that's pretty much it. Just to clarify SimpleHttpConnectionManager
> contains a single instance of an HttpConnection and reuses it when
> possible. For example if you were to do two GETs from
> "http://jakarta.apache.org/" then the connection would be reused. This
> assumes that the server supports connection persistence.
>
> > 3. After connection is established, data is posted, and the result
> > retrieved
> > 4. I do post.releaseConnection(). Does the connection get closed at this
> > point? Is the HttpConnection object still around? What do I need to do if I
> > had wanted to have the connection stay alive (because it takes time to
> > re-establish the connection)?
>
> It depends on the server and a few other variables (like SSL and JVM
> version). In general HTTP 1.1 defaults to keep-alive and 1.0 defaults
> to close. These defaults can be overriden by the server using the
> connection header.
>
> > 5. Is post.recycle() related to connection in any way? What is the purpose
> > of this? Is PostMethod ctor an expensive operation?
>
> It calls releaseConnection() plus some other things. In general I do
> not use recycle much. I prefer to create a new instance as it's not
> particularly expensive.
>
> > 6. SimpleHttpConnectionManager doc says "This manager makes no attempt to
> > provide exclusive access to the contained HttpConnection". Does this mean
> > that calling httpclient.execute() method in this case is not thread-safe?
>
> Correct. Not thread safe. It would fail quite quickly if used from
> multiple threads.
>
> > 7. If I wanted to use "connection pooling" should I be using
> > MultiThreadedHttpConnectionManager instead? Or do I need to implement my
> > own pooling?
>
> MultiThreadedHttpConnectionManager is what you want.
>
> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: Questions related to the use of HttpClient classes
Posted by Michael Becke <be...@u.washington.edu>.
Om,
Nice set of questions. Looks almost like a FAQ :)
> 1. When I do "httpclient = new HttpClient", the object is created by default
> with the SimpleHttpConnectionManager.
Correct.
> 2. I create "post = new PostMethod(url)" and call
> httpclient.executeMethod(post). At this point httpclient takes the url in
> the post object and using the SimpleHttpConnectionManager, creates a
> HttpConnection object. This connection is retained by the
> SimpleHttpConnectionManager and (possibly?) reused.
Yes, that's pretty much it. Just to clarify SimpleHttpConnectionManager
contains a single instance of an HttpConnection and reuses it when
possible. For example if you were to do two GETs from
"http://jakarta.apache.org/" then the connection would be reused. This
assumes that the server supports connection persistence.
> 3. After connection is established, data is posted, and the result
> retrieved
> 4. I do post.releaseConnection(). Does the connection get closed at this
> point? Is the HttpConnection object still around? What do I need to do if I
> had wanted to have the connection stay alive (because it takes time to
> re-establish the connection)?
It depends on the server and a few other variables (like SSL and JVM
version). In general HTTP 1.1 defaults to keep-alive and 1.0 defaults
to close. These defaults can be overriden by the server using the
connection header.
> 5. Is post.recycle() related to connection in any way? What is the purpose
> of this? Is PostMethod ctor an expensive operation?
It calls releaseConnection() plus some other things. In general I do
not use recycle much. I prefer to create a new instance as it's not
particularly expensive.
> 6. SimpleHttpConnectionManager doc says "This manager makes no attempt to
> provide exclusive access to the contained HttpConnection". Does this mean
> that calling httpclient.execute() method in this case is not thread-safe?
Correct. Not thread safe. It would fail quite quickly if used from
multiple threads.
> 7. If I wanted to use "connection pooling" should I be using
> MultiThreadedHttpConnectionManager instead? Or do I need to implement my
> own pooling?
MultiThreadedHttpConnectionManager is what you want.
Mike