axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Mazzucco <Michele.Mazzu...@ncl.ac.uk>
Subject Re: [axis2] SimpleHTTPServer as transport listener causes too many connections to stay in TIME_WAIT state
Date Tue, 05 Feb 2008 18:40:47 GMT
On Tue, 2008-02-05 at 23:40 +0530, Asankha C. Perera wrote:
> Michele
> > I did the following:
> > - updated tomcat from 5.5 to 6.0.14
> > - enabled and tuned the tomcat NIO connector
> The above are ok - but does not affect the synapse-transports-1.1.1.jar 
> at all...
> > - upgraded the NIO listener and sender to synapse 1.1.1 (I had to 
> > upgrade the http-core library from alpha5 to beta1)
> > - enabled the NIO sender on the server side (as I said I have some 
> > ServiceClient instances running on the server too)
> ok..
> > but it didn't fix the problem. Indeed, about 50% of the connections in 
> > TIME_WAIT state are due to the tomcat connector and the other 50% to 
> > the axis2 sender.
> what do you mean "tomcat" connector? If you changed your axis2.xml to 
> enable the o.a.synapse.transport.nhttp package, then *all* of your 
> messages should only be handled by it and not by Tomcat anymore.. you 
> cannot have a mix..
Asankha,

my WS runs inside tomcat, but there are some ServiceClient(s) instances
running in it. 
So I guess incoming requests are handled by the tomcat connector while
outgoing messages are handled by the synapse sender, right?

On the client side, instead, I used the nio transport for both incoming
and outgoing messages.

> > So I enabled the NIO sender and NIO receiver on the client side.
> > My scenario is composed by about 80% of asynchronous interactions and 
> > 20% of very fast blocking in-out MEPs. Now the latter fail this way:
> For optimal usage of server resources you should tune your OS (refer 
> http://wso2.org/library/1721) i.e. at a minimum;
> /etc/sysctl.conf
> net.ipv4.ip_local_port_range = 1024 65535
> net.ipv4.tcp_fin_timeout = 30
> fs.file-max = 2097152
> net.ipv4.tcp_tw_recycle = 1
> net.ipv4.tcp_tw_reuse = 1
> 
> /etc/security/limits.conf
> * soft nofile 4096
> * hard nofile 65535


Ok, thanks. Another link I've found useful is this
http://www.webhostingtalk.com/archive/index.php/t-257654.html


The settings which seem to solve the TIME_WAIT state are the following 

net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
# Disables packet forwarding
net.ipv4.ip_forward=0
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout=25
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time=1800
# Turn on the tcp_window_scaling
net.ipv4.tcp_window_scaling=1


> 
> Also ensure you give enough heap to the Java process, and use HTTP 1.1 
> and Keepalives as much as possible.
> > ERROR 19:44:03,967 (QueueController.java:192) - Unable to add stream 
> > for queue Service2
> > ....
> >
> > The executed statements (related to axis2) are:
> > final OMElement payload = createPayload();
> >
> > ServiceClient sender = new 
> > ServiceClient(AddStreamConfiguration.getConfigurationContext(), null);
> > sender.setOptions(getOptions());
> > OMElement result = sender.sendReceive(payload);
> >
> > where the options are
> > options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
> > options.setCallTransportCleanup(true);
> > options.setTo(StreamClient.getRouterEpr());
> > options.setAction(TestConstants.ADD_STREAM_SOAP_ACTION);
> > options.setSoapVersionURI(SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI);
> > options.setProperty(HTTPConstants.CHUNKED, Boolean.TRUE);
> > options.setProperty(HTTPConstants.AUTO_RELEASE_CONNECTION, Boolean.TRUE);
> >
> > and the configuration context differs from the default one because of 
> > the http connection manager with cached http client.
> I believe the above if for your client - and note that some of the above 
> used properties does not apply to the NIO transport.. However, are you 
> running your client and the server (and anything else related to the 
> test scenario) on the same machine? If so, make sure that the culprit is 
> not the client -

No, the client is on a remote machine. I've tried to use both blocking
and non blocking sender/listener on the client side, and the bottleneck
seems to be the server.

>  I think the above code uses the default HTTP transport 
> that uses the HttpClient codebase.. that may have properties for tuning 
> which I am not fully familiar with..

I think the client uses the transports defined in axis2.xml, it should
not matter which kind of properties you define into the Options.


What do you suggest?, I don't think the problem is the tomcat connector
(I've tried both tomcat 5.5.23 with blocking connector and 6.0.14 with
non blocking one)
> 
Michele

> asankha
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
> 


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


Mime
View raw message