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<[email protected]> 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.thr...@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$s...@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
