You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bob Pollack <ro...@yahoo.com> on 2009/06/01 20:15:40 UTC
Re: JBI In-Only Exchange Never Completes
OK, for the benefit of Mr. Vanthienen and anyone else who may be following
this thread, here is
http://www.nabble.com/file/p23819496/seda-jbi-stuck.txt a thread dump of
the system in a stuck state. If you are trying to follow the dump in detail,
you should be aware that
1. This is an instance of the Camel service engine in which I have
substituted Camel 1.6 for the Camel 1.4 that is included in the normal
download.
2. The Camel SE is running inside an OpenESB JBI container, not ServiceMix
(hence the presence in this dump of packages such as com.sun.jbi.messaging).
For those who don't care about the details, but might be having similar
problems, there are a few things you may want to know:
1. Mr. Vanthienen's suggestion of trying direct URIs in place of SEDA fixed
the problem; this is probably something you should always try if you're
having SEDA problems--I know I will. In this example, changing the two
instances of "seda:mbQueue" to "direct:mbQueue" made the problem go away.
2. This problem was surprisingly hard to reproduce. For example, by the time
I got around to writing this report, I had already moved the XSLT-splitter
logic to another (in-out) JBI service. In this form, the logic worked even
when I had SEDA URIs throughout. Evidently, the cause of this problem is not
as simple as hooking a splitter to a SEDA to an in-only JBI. So,
unfortunately, I can't tell you what constructs to avoid; I'll just
reiterate that if SEDA queues appear to be stuck, try making some of them
"direct."
--
View this message in context: http://www.nabble.com/JBI-In-Only-Exchange-Never-Completes-tp23732734p23819496.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Another SEDA-to-In-Only Problem
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Thanks for your findings.
What version of Camel are you using? I believe we have fixed this in
Camel 1.6.1/2.0.
In these versions the SEDA will leverage the JDK Concurrency API to
shutdown more elegantly.
On Fri, Jun 5, 2009 at 9:45 PM, Bob Pollack<ro...@yahoo.com> wrote:
>
> I have recently encountered what may be either a related problem or the same
> problem, concerning the communication between SEDA queues and in-only JBI
> endpoints. The problem is that when I try to shut down the JBI service
> assembly, the Camel code never terminates.
>
> The routing logic, in a JBI service assembly named PacketService-CamelSA,
> looks like this:
>
> from ("seda:bomInputQueue").inOnly ("jbi:...");
>
> and when I was trying to shut this down, the target component was stuck, so
> it is probable that there were undelivered messages in the SEDA queue.
>
> A thread dump included the follow two stack traces, which I believe are the
> relevant ones. Here's the thread of the service assembly:
>
> Thread "PacketService-CamelSA" thread-id 272 thread-stateWAITINGWaiting on
> lock: java.lang.Thread@58c0be
> at: java.lang.Object.wait(Native Method)
> at: java.lang.Thread.join(Thread.java:1143)
> at: java.lang.Thread.join(Thread.java:1196)
> at:
> org.apache.camel.component.seda.SedaConsumer.doStop(SedaConsumer.java:97)
> at: org.apache.camel.impl.ServiceSupport.stop(ServiceSupport.java:59)
> at:
> org.apache.camel.util.ServiceHelper.stopServices(ServiceHelper.java:110)
> at:
> org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:651)
> at: org.apache.camel.impl.ServiceSupport.stop(ServiceSupport.java:59)
> ...
>
> and here's the thread I believe it is trying to join:
>
> Thread "seda:bomInputQueue thread:1" thread-id 115
> thread-stateWAITINGWaiting on lock:
> java.util.concurrent.CountDownLatch$Sync@16e6127
> at: sun.misc.Unsafe.park(Native Method)
> at: java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at:
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at:
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
> at:
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
> at: java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> at:
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:49)
> at:
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:55)
> at:
> org.apache.camel.processor.LoggingErrorHandler.process(LoggingErrorHandler.java:54)
> at:
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:80)
> at:
> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:52)
> at: org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:69)
> at: java.lang.Thread.run(Thread.java:619)
>
> The relevant code from SedaConsumer looks like this:
>
> protected void doStart() throws Exception {
> thread = new Thread(this, getThreadName(endpoint.getEndpointUri()));
> thread.setDaemon(true);
> thread.start();
> }
>
> protected void doStop() throws Exception {
> thread.join();
> thread = null;
> }
>
> I believe that the doStop() logic should either shut down the other thread
> somehow, or at least add a timeout to the join() statement. If the SEDA
> consumer were inside a free-standing application, I could just kill it, but
> in a JBI environment this is not an option.
>
> --
> View this message in context: http://www.nabble.com/JBI-In-Only-Exchange-Never-Completes-tp23732734p23894406.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Another SEDA-to-In-Only Problem
Posted by Bob Pollack <ro...@yahoo.com>.
I have recently encountered what may be either a related problem or the same
problem, concerning the communication between SEDA queues and in-only JBI
endpoints. The problem is that when I try to shut down the JBI service
assembly, the Camel code never terminates.
The routing logic, in a JBI service assembly named PacketService-CamelSA,
looks like this:
from ("seda:bomInputQueue").inOnly ("jbi:...");
and when I was trying to shut this down, the target component was stuck, so
it is probable that there were undelivered messages in the SEDA queue.
A thread dump included the follow two stack traces, which I believe are the
relevant ones. Here's the thread of the service assembly:
Thread "PacketService-CamelSA" thread-id 272 thread-stateWAITINGWaiting on
lock: java.lang.Thread@58c0be
at: java.lang.Object.wait(Native Method)
at: java.lang.Thread.join(Thread.java:1143)
at: java.lang.Thread.join(Thread.java:1196)
at:
org.apache.camel.component.seda.SedaConsumer.doStop(SedaConsumer.java:97)
at: org.apache.camel.impl.ServiceSupport.stop(ServiceSupport.java:59)
at:
org.apache.camel.util.ServiceHelper.stopServices(ServiceHelper.java:110)
at:
org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:651)
at: org.apache.camel.impl.ServiceSupport.stop(ServiceSupport.java:59)
...
and here's the thread I believe it is trying to join:
Thread "seda:bomInputQueue thread:1" thread-id 115
thread-stateWAITINGWaiting on lock:
java.util.concurrent.CountDownLatch$Sync@16e6127
at: sun.misc.Unsafe.park(Native Method)
at: java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at:
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
at:
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
at:
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
at: java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
at:
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:49)
at:
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:55)
at:
org.apache.camel.processor.LoggingErrorHandler.process(LoggingErrorHandler.java:54)
at:
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:80)
at:
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:52)
at: org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:69)
at: java.lang.Thread.run(Thread.java:619)
The relevant code from SedaConsumer looks like this:
protected void doStart() throws Exception {
thread = new Thread(this, getThreadName(endpoint.getEndpointUri()));
thread.setDaemon(true);
thread.start();
}
protected void doStop() throws Exception {
thread.join();
thread = null;
}
I believe that the doStop() logic should either shut down the other thread
somehow, or at least add a timeout to the join() statement. If the SEDA
consumer were inside a free-standing application, I could just kill it, but
in a JBI environment this is not an option.
--
View this message in context: http://www.nabble.com/JBI-In-Only-Exchange-Never-Completes-tp23732734p23894406.html
Sent from the Camel - Users mailing list archive at Nabble.com.