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/05 21:45:41 UTC

Another SEDA-to-In-Only Problem

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.


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