Hi,
sorry for the late answer. Can you please provide the stacktraces for
the two threads that deadlock? Best you create a JIRA issue with that
information plus a sample application or unit test that represents the
setup/application you're using (even if the deadlock is hard to
reproduce or not reproducible at all in a unit test).
jboyens schrieb:
Hi.
I'm really hoping I'm wrong, but I was doing some load testing with Camel
and an aggregator coming off a asyncSendBody to a direct: component.
I've set the ExecutorThreadPool on the producer so that I can watch what's
going on inside and eventually at about 16 msgs / second the threads start
to lock on the queue's Reentrant lock and deadlock. I've checked with jstack
and confirmed that they lock up on that queue lock.
It looks as though the run() method holds the lock while the enqueueExchange
method attempts to get the same lock and fails because the run() method
never lets it go.
There is a hole that opens up when sendExchanges() runs and the run() method
gives up the lock. So, exchanges will get enqueued at low speeds, but at
higher speeds the bulk up.
