axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: [axis2] SimpleHTTPServer as transport listener causes too many connections to stay in TIME_WAIT state
Date Thu, 07 Feb 2008 08:02:49 GMT

>>>> Not if you are using the NIO listener on the server side and 
>>>> sending requests on the NIO listeners' port..
>>> No, calls were made to the tomcat port.
>> I don't understand what you are trying to achieve here.. if you are 
>> using the o.a.synapse NIO based transports to get over the TIME_WAIT 
>> problems with the Tomcat/Servlet transport, why do you keep sending 
>> messages to the Tomcat port instead of the NIO ports?
> The synapse transports are used for outgoing messages.
I think you should also use the same transports for incoming.. I thought 
you were using Synapse NIO transports to overcome some limitations of 
Tomcat transport?

>> If you want a really good load generator for web service calls, use 
>> the benchmark code from Apache HttpComponents - its as good as or 
>> better than ApacheBench for web services
>> Code - 

>> Binary -
>> Sample / Reference -
> Please correct me if I'm wrong, but it looks to me that your client is 
> deterministic, i.e. does not introduce any randomness (for example for 
> the arrival rate, I'd like an average value of x, but with some 
> distribution, not via constant values) -- which is very important in 
> real systems.
Well it behaves like Apache Bench - you can specify concurrency and that 
number of threads are spawned, and each of these threads start sending 
the specified number of requests one after another.. you can get this 
code from Apache HttpCore and easily modify it to introduce randomness, 
and even contribute your changes back

>>> No, I've written the client, and it's pretty optimized.
>> Can you share a TCPDump of a sample request made by your client and 
>> the response received.. in particular I am interested to know if you use
>> 1. HTTP 1.1
>> 2. Keepalive connections
>> 3. Chunking
> I've tried all the possible combinations.
> Currently I'm using the NIO transports on the client side as well, and 
> by default java uses http 1.1, which in turn uses keep alive by default.
> Is there any way to customize the NIO sender behavior?
Yes, by making a property file called "" available on 
the classpath. Look at the NHttpConfiguration class for more details - 
However note that the defaults are very much cable of handling huge loads


> I know how to change SO_TIMEOUT and so on, 
You can change things like SO_TIMEOUT, CONNECTION_TIMEOUT, 
HttpCoreNIOSender.getClientParameters() method
> but how can I change -- for example -- the max number of requests that 
> are sent over the same channel (the tomcat NIO connector allows such 
> thing)?
You mean for re-using existing connections? if so there is no limit, if 
a free channel is 'available' it will be used


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message