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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
