On Tue, Sep 21, 2010 at 02:15, Glen Daniels <[email protected]> wrote: > 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.
That would mean that there is a valid scenario where two invocations are blocked on the server side waiting for a third invocation. I don't know the details of WS-RM, but this seems very unlikely to me. > 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. By increasing that value (which might indeed be a good idea for other reasons) you will always be able to work around the issue. However, you will probably miss an opportunity to fix a bug in Sandesha. > --Glen > > --------------------------------------------------------------------- > 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]
