Hi Michael, apparently your config didn't came through the moderation interface. Could you try sending it again (after subscribing to the mailinglist) or sending a link to a gist instead? In general ODE can deal with such deadlocks and will schedule retries using an exponential backoff. As a rule of thumb, the DB connection pool size should be greater than the thread pool size, which can be around 15 threads per core. This should equally saturate all cores. Also the database should be configured to handle as many connections as well.
If the deadlocks persist, perhaps the IO to the database is the bottleneck. In this case I'd try to reduce the number of worker threads. HTH, Tammo On Tue, Jan 21, 2014 at 10:20 AM, Servaas, M. (Michael) < [email protected]> wrote: > Hi sathwik, > > What you are referring to was a run with fewer connections (5), normally I > would run with 150 and have tried more. In the end it will always fail. For > instance with 500 connections it fails after a few load test runs, but may > fail sooner. > The load I'm testing with is 10 requests per second. With 1 request per > second, there seem to be no problems although I haven't tested for longer > periods of time. > > Seems to me ODE should run with fewer connections but just take longer to > process? Something like when no more connections are available, > threads should wait until there are? Connections should always be returned > to the pool at some point (when a bpel process is completed maybe). > > I have attached my ode-axis2.properties. My bpel process is quite simple, > though asynchronous. I receive a request, copy some variables, send a > request and receive the answer via callback. Some correlation on the > callback, variable copying and sending the final result to the original > caller via callback. Also there's some cleanup afterwards. > > Hope this helps. > > Regards, > > Michael > > > > > > > -------------------------Disclaimer------------------------------- > De informatie verzonden met dit e-mailbericht (en bijlagen) is uitsluitend > bestemd voor de geadresseerde(n) en zij die van de geadresseerde(n) > toestemming kregen dit bericht te lezen. Gebruik door anderen dan > geadresseerde(n) is verboden. De informatie in dit e-mailbericht (en > bijlagen) kan vertrouwelijk van aard zijn en kan binnen het bereik vallen > van een geheimhoudingsplicht en een verschoningsrecht. > ------------------------------------------------------------------- > -- Tammo van Lessen - http://www.taval.de
