You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Aaron <at...@gmail.com> on 2005/11/30 00:19:02 UTC

HttpClient/TCP experts--how do I rapidly use http connections?

In my email (inlined below) you'll see a description of how I am using
HTTP client to rapidly generate HTTP post requests to a server--for
performance testing purposes.  The tool I'm writing creates a
multi-threaded HttpClient object (configured w/
MultiThreadedConnectionManager) and then kicks off N threads that each
use this object to execute PostMethods.  When any of the N threads
finishes its request and releases the connection, a new thread takes
its place and executes a PostMethod.  And so on--so that effectively
my tool is greedily keeping 10 PostMethods executing at any given
time.

Each thread is executing code that looks like this:

// client thread
...
final long start = sampleTime();
myHttpClient.executeMethod(post);
final long finish = sampleTime();
reportResponseTime(finish - start);
...

At first I was getting BindExceptions when I configured the tool to
use N > 5 concurrent threads.  I resolved this by registering my own
http socket factory with HttpClient--*my* socket factory did this:

{
   socket = createSocket();
   socket.setReuseAddress(true); // *** This is the important change ***
   return socket;
}

This alleviated my BindExceptions, HOWEVER setting reuseAddress to
true caused my response times to go up--even for cases where N <= 5.
That is,  I was getting better response times when I didn't set
reuseAddress.

My response times improve (in all cases) when I introduce a
significant sleep time (e.g., 1s) at the end of each thread (before it
allows another thread to wake and execute a post method)--HOWEVER, I
do not want to throttle my throughput like this.

I suspect that there is some TCP/HttpClient related issues here that I
do not understand completely.  Is there an expert on this that can
give me some insight into this problem?  Why did setReuseAddress(true)
prevent the BindExceptions, but cause greater response times?  How do
I reuse http connections or execute post methods as fast as possible,
without effecting my response times?

Thanks for any help!!

Aaron



On 11/16/05, Rajat Sharma <rs...@airvananet.com> wrote:
> a) You can try reusing your connections for the subsequent post methods, if this fits in your test scenario.
> b) Put socket timeout. ttpClient.setTimeout() andHttpClient.setConnectionTimeout() should suffice.
> c) Bind exceptions can also come since on Unix there is a limit of number of total TCP sockets you can open. This limit is 1024. You can increase this limit
>   by ulimit command.
>
> I hope it helps.
> Raj
>
> -----Original Message-----
> From: Aaron [mailto:atdixon@gmail.com]
> Sent: Wednesday, November 16, 2005 3:25 PM
> To: httpclient-user@jakarta.apache.org
> Subject: rapid http connection use
>
>
> Hi,
>
> I am writing a performance testing tool that uses HttpClient; the tool
> kicks off N threads, and each thread creates a PostMethod and executes
> it via an HttpClient instance (configured with
> MultiThreadedHttpConnectionManager). When each request thread
> finishes, another thread takes its place immediately and
> creates/executes another post method using the same HttpClient.  The
> result is that I am rapidly creating PostMethods and executing them.
> (I am ensuring that releaseConnection() is called in each thread.)
>
> I am getting repeated java.net.BindExceptions, and I understand from
> the research that I've done that this can happen if you are creating
> socket connections so rapidly.  This has to do with TCP connections
> sitting in a CLOSED state for some time after being closed.
>
> My tool can be configured to have each request thread sleep some
> number of milliseconds after releasing its connection.  When I
> configure this sleep time to be high (~1 sec), the BindExceptions go
> away.  I assume this is time needed for the released TCP connection to
> leave its CLOSED state.  However, that this sleep time must be so high
> is what concerns me.
>
> HttpClient experts, can you help me around this issue?  How do I
> dispatch these threads more quickly, without getting BindExceptions?
>
> Thanks for any insights--
>
> Aaron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


AW: HttpClient/TCP experts--how do I rapidly use http connections?

Posted by Ingo Meyer <dj...@gmx.net>.
Hi Aaron,

I have another error fitting in this case.
My App is for distributing some mathematical working stuff.
I have a Tomcat where my Client connects to and gets some
rough data. Then it calculates the results and post it back.
As I have much data the app uses therefore 150 threads to
d/l and post. Appr. 50 of them are calculating and the other
are d/l or u/l.
Ok so far. My experience now is, that windows (or maybe java)
after you free a socket, does not give it free for some seconds.
I mean I've read something about this somewhere. But you can
see it if you use TCPView 2.4 from www.sysinternals.com.
So it may be a normal thing on windows. I have not tested
yet on linux.
In my case I never get a bind exception cause the calculation time 
is long enough, but my problem is the following:
When I want to use proxies for the connection (to anonymize the clients,
it should be a system like s.e.t.i. and the server should not know which
client gets how much data) and the the speed breaks down to a tenth part.
This may be because the MTCM tries to reuse the connection, but the proxy
are often to slow or reject the connection (free avail anon proxies are
really
bad), so I now tried to give the connection always free.

Code:

public class AlwaysClosingMultiThreadedHttpConnectionManager
	extends MultiThreadedHttpConnectionManager
{
	public void releaseConnection (
		HttpConnection conn)
	{
		conn.close ();
		super.releaseConnection (conn);
	}

}

Have I done this right?

Thanks,
Ingo 

> -----Ursprüngliche Nachricht-----
> Von: Aaron [mailto:atdixon@gmail.com] 
> Gesendet: Mittwoch, 30. November 2005 00:51
> An: HttpClient User Discussion
> Betreff: Re: HttpClient/TCP experts--how do I rapidly use 
> http connections?
> 
> Sam,
> 
> Thanks for the quick response! We're running this tool on a 
> Windows machine, which allows creation of sockets across a 
> range of roughly 4000 ports--we were seeing the 
> BindExceptions after a short duration, so I think that means 
> we were consuming these ports too quickly.
> 
> Your conjecture that the "OS is doing more work to recycle the port"
> in the case of setReuseAddress(true) is a sensible 
> theory--can anyone verify?
> 
> What concerns me, or what I ultimately don't understand, is 
> why in both cases, to rid myself of the BindExceptions or to 
> improve my response times, I have to set relatively high 
> sleep times in my threads. I suppose what's happening in 
> these sleep times, is I'm
> allowing Windows/Java/HttpClient time to recycle the connection.   It
> seems that when I use sleep times lower than 1s, my response 
> times are noticeably affected or I get those BindExceptions.
> 
> So is Windows really *that* slow at recycling TCP 
> connections?  Then how do high-performance servers work to 
> accept so many incoming connections?  Is there a way around 
> this, besides running my tool simultaneously on a 100 machines?
> 
> Thanks again!
> 
> Aaron
> 
> On 11/29/05, Sam Berlin <sb...@gmail.com> wrote:
> > Hi Aaaron,
> >
> > Assuming you already tried the ulimit suggestion that Rajat 
> mentioned, 
> > the reason this may be happening is because you're really 
> doing a lot 
> > of socket creations.  Do the BindExceptions happen immediately, or 
> > after a short bit of the program running?  If it's after a while, I 
> > can only guess that the app created so many sockets that it 
> ran out of 
> > local ports to give to a newly created socket.  Setting 
> > setReuseAddress to true lets you reuse already-used ports, so it'll 
> > never run out.  If the response times are going up when that's set, 
> > it's likely because the OS is doing more work to recycle the port.
> > All of this is conjecture, of course, but I can't think of 
> any other 
> > reason you'd be seeing what you're seeing.
> >
> > Thanks,
> >  Sam
> >
> >
> > On 11/29/05, Aaron <at...@gmail.com> wrote:
> > > In my email (inlined below) you'll see a description of how I am 
> > > using HTTP client to rapidly generate HTTP post requests to a 
> > > server--for performance testing purposes.  The tool I'm writing 
> > > creates a multi-threaded HttpClient object (configured w/
> > > MultiThreadedConnectionManager) and then kicks off N threads that 
> > > each use this object to execute PostMethods.  When any of the N 
> > > threads finishes its request and releases the connection, a new 
> > > thread takes its place and executes a PostMethod.  And so on--so 
> > > that effectively my tool is greedily keeping 10 PostMethods 
> > > executing at any given time.
> > >
> > > Each thread is executing code that looks like this:
> > >
> > > // client thread
> > > ...
> > > final long start = sampleTime();
> > > myHttpClient.executeMethod(post);
> > > final long finish = sampleTime();
> > > reportResponseTime(finish - start);
> > > ...
> > >
> > > At first I was getting BindExceptions when I configured 
> the tool to 
> > > use N > 5 concurrent threads.  I resolved this by 
> registering my own 
> > > http socket factory with HttpClient--*my* socket factory did this:
> > >
> > > {
> > >   socket = createSocket();
> > >   socket.setReuseAddress(true); // *** This is the 
> important change ***
> > >   return socket;
> > > }
> > >
> > > This alleviated my BindExceptions, HOWEVER setting 
> reuseAddress to 
> > > true caused my response times to go up--even for cases 
> where N <= 5.
> > > That is,  I was getting better response times when I didn't set 
> > > reuseAddress.
> > >
> > > My response times improve (in all cases) when I introduce a 
> > > significant sleep time (e.g., 1s) at the end of each 
> thread (before 
> > > it allows another thread to wake and execute a post 
> > > method)--HOWEVER, I do not want to throttle my throughput 
> like this.
> > >
> > > I suspect that there is some TCP/HttpClient related 
> issues here that 
> > > I do not understand completely.  Is there an expert on 
> this that can 
> > > give me some insight into this problem?  Why did 
> > > setReuseAddress(true) prevent the BindExceptions, but 
> cause greater 
> > > response times?  How do I reuse http connections or execute post 
> > > methods as fast as possible, without effecting my response times?
> > >
> > > Thanks for any help!!
> > >
> > > Aaron
> > >
> > >
> > >
> > > On 11/16/05, Rajat Sharma <rs...@airvananet.com> wrote:
> > > > a) You can try reusing your connections for the 
> subsequent post methods, if this fits in your test scenario.
> > > > b) Put socket timeout. ttpClient.setTimeout() 
> andHttpClient.setConnectionTimeout() should suffice.
> > > > c) Bind exceptions can also come since on Unix there is 
> a limit of number of total TCP sockets you can open. This 
> limit is 1024. You can increase this limit
> > > >   by ulimit command.
> > > >
> > > > I hope it helps.
> > > > Raj
> > > >
> > > > -----Original Message-----
> > > > From: Aaron [mailto:atdixon@gmail.com]
> > > > Sent: Wednesday, November 16, 2005 3:25 PM
> > > > To: httpclient-user@jakarta.apache.org
> > > > Subject: rapid http connection use
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I am writing a performance testing tool that uses 
> HttpClient; the 
> > > > tool kicks off N threads, and each thread creates a 
> PostMethod and 
> > > > executes it via an HttpClient instance (configured with 
> > > > MultiThreadedHttpConnectionManager). When each request thread 
> > > > finishes, another thread takes its place immediately and 
> > > > creates/executes another post method using the same 
> HttpClient.  
> > > > The result is that I am rapidly creating PostMethods 
> and executing them.
> > > > (I am ensuring that releaseConnection() is called in 
> each thread.)
> > > >
> > > > I am getting repeated java.net.BindExceptions, and I understand 
> > > > from the research that I've done that this can happen 
> if you are 
> > > > creating socket connections so rapidly.  This has to do 
> with TCP 
> > > > connections sitting in a CLOSED state for some time 
> after being closed.
> > > >
> > > > My tool can be configured to have each request thread 
> sleep some 
> > > > number of milliseconds after releasing its connection.  When I 
> > > > configure this sleep time to be high (~1 sec), the 
> BindExceptions 
> > > > go away.  I assume this is time needed for the released TCP 
> > > > connection to leave its CLOSED state.  However, that this sleep 
> > > > time must be so high is what concerns me.
> > > >
> > > > HttpClient experts, can you help me around this issue?  
> How do I 
> > > > dispatch these threads more quickly, without getting 
> BindExceptions?
> > > >
> > > > Thanks for any insights--
> > > >
> > > > Aaron
> > > >
> > > > 
> ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: 
> > > > httpclient-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > > > httpclient-user-help@jakarta.apache.org
> > > >
> > > >
> > > > 
> ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: 
> > > > httpclient-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > > > httpclient-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > 
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: 
> > > httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> > > httpclient-user-help@jakarta.apache.org
> > >
> > >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: 
> httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: 
> > httpclient-user-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> httpclient-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Re: HttpClient/TCP experts--how do I rapidly use http connections?

Posted by Aaron <at...@gmail.com>.
Sam,

Thanks for the quick response! We're running this tool on a Windows
machine, which allows creation of sockets across a range of roughly
4000 ports--we were seeing the BindExceptions after a short duration,
so I think that means we were consuming these ports too quickly.

Your conjecture that the "OS is doing more work to recycle the port"
in the case of setReuseAddress(true) is a sensible theory--can anyone
verify?

What concerns me, or what I ultimately don't understand, is why in
both cases, to rid myself of the BindExceptions or to improve my
response times, I have to set relatively high sleep times in my
threads. I suppose what's happening in these sleep times, is I'm
allowing Windows/Java/HttpClient time to recycle the connection.   It
seems that when I use sleep times lower than 1s, my response times are
noticeably affected or I get those BindExceptions.

So is Windows really *that* slow at recycling TCP connections?  Then
how do high-performance servers work to accept so many incoming
connections?  Is there a way around this, besides running my tool
simultaneously on a 100 machines?

Thanks again!

Aaron

On 11/29/05, Sam Berlin <sb...@gmail.com> wrote:
> Hi Aaaron,
>
> Assuming you already tried the ulimit suggestion that Rajat mentioned,
> the reason this may be happening is because you're really doing a lot
> of socket creations.  Do the BindExceptions happen immediately, or
> after a short bit of the program running?  If it's after a while, I
> can only guess that the app created so many sockets that it ran out of
> local ports to give to a newly created socket.  Setting
> setReuseAddress to true lets you reuse already-used ports, so it'll
> never run out.  If the response times are going up when that's set,
> it's likely because the OS is doing more work to recycle the port.
> All of this is conjecture, of course, but I can't think of any other
> reason you'd be seeing what you're seeing.
>
> Thanks,
>  Sam
>
>
> On 11/29/05, Aaron <at...@gmail.com> wrote:
> > In my email (inlined below) you'll see a description of how I am using
> > HTTP client to rapidly generate HTTP post requests to a server--for
> > performance testing purposes.  The tool I'm writing creates a
> > multi-threaded HttpClient object (configured w/
> > MultiThreadedConnectionManager) and then kicks off N threads that each
> > use this object to execute PostMethods.  When any of the N threads
> > finishes its request and releases the connection, a new thread takes
> > its place and executes a PostMethod.  And so on--so that effectively
> > my tool is greedily keeping 10 PostMethods executing at any given
> > time.
> >
> > Each thread is executing code that looks like this:
> >
> > // client thread
> > ...
> > final long start = sampleTime();
> > myHttpClient.executeMethod(post);
> > final long finish = sampleTime();
> > reportResponseTime(finish - start);
> > ...
> >
> > At first I was getting BindExceptions when I configured the tool to
> > use N > 5 concurrent threads.  I resolved this by registering my own
> > http socket factory with HttpClient--*my* socket factory did this:
> >
> > {
> >   socket = createSocket();
> >   socket.setReuseAddress(true); // *** This is the important change ***
> >   return socket;
> > }
> >
> > This alleviated my BindExceptions, HOWEVER setting reuseAddress to
> > true caused my response times to go up--even for cases where N <= 5.
> > That is,  I was getting better response times when I didn't set
> > reuseAddress.
> >
> > My response times improve (in all cases) when I introduce a
> > significant sleep time (e.g., 1s) at the end of each thread (before it
> > allows another thread to wake and execute a post method)--HOWEVER, I
> > do not want to throttle my throughput like this.
> >
> > I suspect that there is some TCP/HttpClient related issues here that I
> > do not understand completely.  Is there an expert on this that can
> > give me some insight into this problem?  Why did setReuseAddress(true)
> > prevent the BindExceptions, but cause greater response times?  How do
> > I reuse http connections or execute post methods as fast as possible,
> > without effecting my response times?
> >
> > Thanks for any help!!
> >
> > Aaron
> >
> >
> >
> > On 11/16/05, Rajat Sharma <rs...@airvananet.com> wrote:
> > > a) You can try reusing your connections for the subsequent post methods, if this fits in your test scenario.
> > > b) Put socket timeout. ttpClient.setTimeout() andHttpClient.setConnectionTimeout() should suffice.
> > > c) Bind exceptions can also come since on Unix there is a limit of number of total TCP sockets you can open. This limit is 1024. You can increase this limit
> > >   by ulimit command.
> > >
> > > I hope it helps.
> > > Raj
> > >
> > > -----Original Message-----
> > > From: Aaron [mailto:atdixon@gmail.com]
> > > Sent: Wednesday, November 16, 2005 3:25 PM
> > > To: httpclient-user@jakarta.apache.org
> > > Subject: rapid http connection use
> > >
> > >
> > > Hi,
> > >
> > > I am writing a performance testing tool that uses HttpClient; the tool
> > > kicks off N threads, and each thread creates a PostMethod and executes
> > > it via an HttpClient instance (configured with
> > > MultiThreadedHttpConnectionManager). When each request thread
> > > finishes, another thread takes its place immediately and
> > > creates/executes another post method using the same HttpClient.  The
> > > result is that I am rapidly creating PostMethods and executing them.
> > > (I am ensuring that releaseConnection() is called in each thread.)
> > >
> > > I am getting repeated java.net.BindExceptions, and I understand from
> > > the research that I've done that this can happen if you are creating
> > > socket connections so rapidly.  This has to do with TCP connections
> > > sitting in a CLOSED state for some time after being closed.
> > >
> > > My tool can be configured to have each request thread sleep some
> > > number of milliseconds after releasing its connection.  When I
> > > configure this sleep time to be high (~1 sec), the BindExceptions go
> > > away.  I assume this is time needed for the released TCP connection to
> > > leave its CLOSED state.  However, that this sleep time must be so high
> > > is what concerns me.
> > >
> > > HttpClient experts, can you help me around this issue?  How do I
> > > dispatch these threads more quickly, without getting BindExceptions?
> > >
> > > Thanks for any insights--
> > >
> > > Aaron
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Re: HttpClient/TCP experts--how do I rapidly use http connections?

Posted by Sam Berlin <sb...@gmail.com>.
Hi Aaaron,

Assuming you already tried the ulimit suggestion that Rajat mentioned,
the reason this may be happening is because you're really doing a lot
of socket creations.  Do the BindExceptions happen immediately, or
after a short bit of the program running?  If it's after a while, I
can only guess that the app created so many sockets that it ran out of
local ports to give to a newly created socket.  Setting
setReuseAddress to true lets you reuse already-used ports, so it'll
never run out.  If the response times are going up when that's set,
it's likely because the OS is doing more work to recycle the port. 
All of this is conjecture, of course, but I can't think of any other
reason you'd be seeing what you're seeing.

Thanks,
 Sam


On 11/29/05, Aaron <at...@gmail.com> wrote:
> In my email (inlined below) you'll see a description of how I am using
> HTTP client to rapidly generate HTTP post requests to a server--for
> performance testing purposes.  The tool I'm writing creates a
> multi-threaded HttpClient object (configured w/
> MultiThreadedConnectionManager) and then kicks off N threads that each
> use this object to execute PostMethods.  When any of the N threads
> finishes its request and releases the connection, a new thread takes
> its place and executes a PostMethod.  And so on--so that effectively
> my tool is greedily keeping 10 PostMethods executing at any given
> time.
>
> Each thread is executing code that looks like this:
>
> // client thread
> ...
> final long start = sampleTime();
> myHttpClient.executeMethod(post);
> final long finish = sampleTime();
> reportResponseTime(finish - start);
> ...
>
> At first I was getting BindExceptions when I configured the tool to
> use N > 5 concurrent threads.  I resolved this by registering my own
> http socket factory with HttpClient--*my* socket factory did this:
>
> {
>   socket = createSocket();
>   socket.setReuseAddress(true); // *** This is the important change ***
>   return socket;
> }
>
> This alleviated my BindExceptions, HOWEVER setting reuseAddress to
> true caused my response times to go up--even for cases where N <= 5.
> That is,  I was getting better response times when I didn't set
> reuseAddress.
>
> My response times improve (in all cases) when I introduce a
> significant sleep time (e.g., 1s) at the end of each thread (before it
> allows another thread to wake and execute a post method)--HOWEVER, I
> do not want to throttle my throughput like this.
>
> I suspect that there is some TCP/HttpClient related issues here that I
> do not understand completely.  Is there an expert on this that can
> give me some insight into this problem?  Why did setReuseAddress(true)
> prevent the BindExceptions, but cause greater response times?  How do
> I reuse http connections or execute post methods as fast as possible,
> without effecting my response times?
>
> Thanks for any help!!
>
> Aaron
>
>
>
> On 11/16/05, Rajat Sharma <rs...@airvananet.com> wrote:
> > a) You can try reusing your connections for the subsequent post methods, if this fits in your test scenario.
> > b) Put socket timeout. ttpClient.setTimeout() andHttpClient.setConnectionTimeout() should suffice.
> > c) Bind exceptions can also come since on Unix there is a limit of number of total TCP sockets you can open. This limit is 1024. You can increase this limit
> >   by ulimit command.
> >
> > I hope it helps.
> > Raj
> >
> > -----Original Message-----
> > From: Aaron [mailto:atdixon@gmail.com]
> > Sent: Wednesday, November 16, 2005 3:25 PM
> > To: httpclient-user@jakarta.apache.org
> > Subject: rapid http connection use
> >
> >
> > Hi,
> >
> > I am writing a performance testing tool that uses HttpClient; the tool
> > kicks off N threads, and each thread creates a PostMethod and executes
> > it via an HttpClient instance (configured with
> > MultiThreadedHttpConnectionManager). When each request thread
> > finishes, another thread takes its place immediately and
> > creates/executes another post method using the same HttpClient.  The
> > result is that I am rapidly creating PostMethods and executing them.
> > (I am ensuring that releaseConnection() is called in each thread.)
> >
> > I am getting repeated java.net.BindExceptions, and I understand from
> > the research that I've done that this can happen if you are creating
> > socket connections so rapidly.  This has to do with TCP connections
> > sitting in a CLOSED state for some time after being closed.
> >
> > My tool can be configured to have each request thread sleep some
> > number of milliseconds after releasing its connection.  When I
> > configure this sleep time to be high (~1 sec), the BindExceptions go
> > away.  I assume this is time needed for the released TCP connection to
> > leave its CLOSED state.  However, that this sleep time must be so high
> > is what concerns me.
> >
> > HttpClient experts, can you help me around this issue?  How do I
> > dispatch these threads more quickly, without getting BindExceptions?
> >
> > Thanks for any insights--
> >
> > Aaron
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org