Hi Gert. I've been taking care of ending correctly all of the exchanges, so for sure it's got to do with the second thing you say: I've got to use send() instead of sendSync(). My scenario is a bean calling another bean using sendSync(), so the first one must be waiting for the answer and the second one waiting for the thread to be free, exactly as you say. I've seen the thread-pools configuration and by doing some tuning I can only make it harder to come to the blockage (i.e maybe needing 100 threads to be open at once), but I cannot prevent it.
I'll try to change my scenario in some way to be able to call asynchronously, as it looks like that's the solution. Thanks a lot for the answer. Best regards. Sebastian Gomez. On Tue, Dec 16, 2008 at 10:07 AM, Gert Vanthienen <[email protected] > wrote: > Sebastian, > > First of all, make sure that all your MEPs are handled correctly, ie. every > MessageExchange ends with either a DONE or ERROR status. > The best way to ensure scalability is by avoiding the use of sendSync() and > by using send() for all your MessageExchanges. When you use sendSync(), > that component thread is blocked until you receive an answer. However, this > also means that there is one less thread available in the thread pool to > handle new requests. You might end up in a situation where all you threads > are waiting on a sendSync(), while the handling of the message is waiting > for one of these threads to be released. You can check this by looking at > the threads in jconsole and especially at their stack traces when the system > gets blocked. > > If you're already using send() everywhere and all MEPs are handled > correctly, but seda queues are still growing, you can tune the thread pool > for a specific component (as explained in > http://servicemix.apache.org/thread-pools.html) to allow it to handle more > messages concurrently. > > Regards, > > Gert > > > Sebastian Gomez wrote: > >> Hi everyone. >> I'm about to finish a project using ServiceMix 3.2.2, and after doing some >> stress tests I've found that if I send lots of messages to the same >> servicemix-bean endpoint to do quite complex operations (they take a long >> time and should return quite large amounts of data, including >> attachments), >> the Seda Queue finally gets stuck. The only way I've found to "unstuck" it >> is to restart ServiceMix (something I won't be able to do after handing in >> my application). >> >> Debugging I've seen my application reaches the SedaFlow "doSend" method, >> it >> enqueues the packet correctly, but I suppose it never dequeues (how could >> I >> see if this is true?). >> >> I've seen using jconsole that servicemix-bean's Seda Queue size keeps >> increasing as I send messages into my application, and never decreases, so >> there must be something going wrong. I'd like to know if there's some >> known >> issue involving this, and if luckily there's some kind of solution. >> >> My project's deadline is near, so I'd really appreciate any help. >> >> Thanks in advance. >> >> Sebastian Gomez. >> >> >> > >
