On 9/20/2010 2:52 PM, Andreas Veithen wrote: > The real issue is that by design (more precisely because of deferred > parsing of response messages), it is mandatory to call > TransportSender#cleanup(MessageContext) after processing a response. > When using a ServiceClient, this is done explicitly by a call to > ServiceClient#cleanupTransport() or implicitly when sending another > request. However, Rampart and Sandesha were lacking the necessary > invocations of cleanupTransport. For Rampart, I was able to locate the > problematic code and fixed the issue in r992868. I did an attempt to > fix the issue in Sandesha, but it looks like this is more complicated > than Rampart. So, we need somebody familiar with the Sandesha code to > determine where these calls are missing.
I'm wondering if this isn't something to do with Sandesha opening up another (server) connection for ACKs and sharing the same ConfigurationContext with the client-side, therefore running into the default 2-connection limit on the shared connection manager. I haven't dug in detail into the problem yet either, but I wonder if manually setting a MultithreadedHTTPConnectionManager with a higher number of connections per host might help. If so, we can work around this in Sandesha and then consider raising the default from 2 to maybe 6. --Glen --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
