This could be caused by a combination of problems under high load. The default configuration of the thread pools is to create new threads while the number of threads is below a given limit, then queue the exchanges in a collection until the collection is full. When no threads are available and the collection is full, the thread sending the exchange will process it instead of queuing it. The goal is to slow the consumers and not loose any messages. However, some problems may appear when using sendSync, because in an InOut exchange, both components could use sendSync. This work when using different threads, but when a single thread is involved (as it would be the case if the queues are full), this completely fail and not error is thrown anywhere (I don't recall exactly what would happen, but It may the case that the thread is waiting forever on an event that will never come). So raising the number of threads should work around the problem. I'm not sure however about the "Exchange not found" error.
On Thu, Jul 24, 2008 at 6:05 PM, ninckblokje <[EMAIL PROTECTED]> wrote: > > Hi all, > > We have made some progress on the problem I mentioned earlier. > This problem occurs when the number of threads run out. The number of > threads can be specified in servicemix.properties. You can increase all > properties, but the property corePoolSize is the most important one. I am > not sure what cases this behaviour, but increasing the number of threads is > a nice work around. > The HTTP consumer endpoint dies because of the resulting Exception. By > implementing the suggested fix for SM-1294 you can prevent the HTTP consumer > endpoint from dying. This could be the fix for SM-1179. > > Jeroen NB > -- > View this message in context: > http://www.nabble.com/ConsumerProcessor---Exchange-not-found-tp16581070p18635124.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
