Return-Path: Delivered-To: apmail-activemq-camel-user-archive@locus.apache.org Received: (qmail 25420 invoked from network); 25 Jul 2008 15:10:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Jul 2008 15:10:18 -0000 Received: (qmail 49872 invoked by uid 500); 25 Jul 2008 15:10:17 -0000 Delivered-To: apmail-activemq-camel-user-archive@activemq.apache.org Received: (qmail 49859 invoked by uid 500); 25 Jul 2008 15:10:17 -0000 Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: camel-user@activemq.apache.org Delivered-To: mailing list camel-user@activemq.apache.org Received: (qmail 49848 invoked by uid 99); 25 Jul 2008 15:10:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Jul 2008 08:10:17 -0700 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Jul 2008 15:09:20 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KMOvR-0004pS-8L for camel-user@activemq.apache.org; Fri, 25 Jul 2008 08:09:45 -0700 Message-ID: <18653593.post@talk.nabble.com> Date: Fri, 25 Jul 2008 08:09:45 -0700 (PDT) From: Piotr Jagielski To: camel-user@activemq.apache.org Subject: Re: Servicemix/Camel problem - ToJbiProcessor hangs In-Reply-To: <4889D7F1.8060402@skynet.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: pjagielski@o2.pl References: <4889D214.9050109@gmail.com> <4889D7F1.8060402@skynet.be> X-Virus-Checked: Checked by ClamAV on apache.org Gert, In this case only camel jms listener thread hangs, other servicemix components threads are just waiting like: "pool-component.servicemix-http-thread-1" prio=1 tid=0x00002aaab8193500 nid=0x4d97 waiting on condition [0x0000000047611000..0x0000000047611c40] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1803) at java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:286) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:270) at org.apache.servicemix.common.AsyncBaseLifeCycle.pollDeliveryChannel(AsyncBaseLifeCycle.java:314) at org.apache.servicemix.common.AsyncBaseLifeCycle$1.run(AsyncBaseLifeCycle.java:300) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) There is one pool-component-servicemix-http thread with stack like: "pool-component.servicemix-http-thread-1" prio=1 tid=0x00002aaab8193500 nid=0x4d97 waiting on condition [0x0000000047611000..0x0000000047611c40] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1803) at java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:286) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:270) at org.apache.servicemix.common.AsyncBaseLifeCycle.pollDeliveryChannel(AsyncBaseLifeCycle.java:314) at org.apache.servicemix.common.AsyncBaseLifeCycle$1.run(AsyncBaseLifeCycle.java:300) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Is it possible to recover from this by setting some timeout on jms transaction manager? My route definition is: from("activemq:queueA").policy(required) .to("jbi:endpoint:B") Regards, Piotr Gert Vanthienen wrote: > > Piotr, > > I'm guessing that at some point, the message you sent to the jbi > endpoint ends up in another Camel route. ServiceMix has a thread pool > per component, so in order to process the exchange in the second Camel > route, it needs another thread from the pool, where all threads are > already waiting on sendSync. > > We should probably improve the servicemix-camel component to use send() > instead of sendSync() whenever possible. For now, you should try to > increase the size of the thread pools by modifying > conf/servicemix.properties (for a global increase of thread pool size) > or by looking at http://servicemix.apache.org/thread-pools.html for a > more targeted tuning. > > Regards, > > Gert > > Piotr Jagielski wrote: >> Hi, >> >> I have some servicemix-camel service unit which uses following route: >> jms queue -> jbi endpoint >> >> After launching some long-running tests, following error occured : >> >> Exception in thread "ActiveMQ Transport: tcp:///127.0.0.1:41368" >> java.lang.ArrayIndexOutOfBoundsException: 28515 >> >---at >> org.apache.activemq.openwire.OpenWireFormat.getFromUnmarshallCache(OpenWireFormat.java:513) >> >> >---at >> org.apache.activemq.openwire.v2.BaseDataStreamMarshaller.tightUnmarsalCachedObject(BaseDataStreamMarshaller.java:137) >> >> >---at >> org.apache.activemq.openwire.v2.ConnectionInfoMarshaller.tightUnmarshal(ConnectionInfoMarshaller.java:69) >> >> >---at >> org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:347) >> >> >---at >> org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:273) >> >> >---at >> org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:156) >> >> >---at >> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) >> >---at java.lang.Thread.run(Thread.java:595) >> >> This exception is not itself a problem, but when i looked at thread >> dump, it appeared that ToJbiProcessor hung on DeliveryChannel.sendSync : >> >> "DefaultMessageListenerContainer-1776" prio=1 tid=0x00002aaaaea39ee0 >> nid=0x4547 in Object.wait() [0x00000000539d3000..0x00000000539d4e40] >> at java.lang.Object.wait(Native Method) >> - waiting on <0x00002afd9884a428> (a >> org.apache.servicemix.jbi.messaging.InOutImpl) >> at >> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.waitForExchange(DeliveryChannelImpl.java:699) >> >> at >> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:472) >> >> - locked <0x00002afd9884a428> (a >> org.apache.servicemix.jbi.messaging.InOutImpl) >> at >> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:442) >> >> at >> org.apache.servicemix.camel.ToJbiProcessor.process(ToJbiProcessor.java:76) >> >> at >> org.apache.servicemix.camel.JbiEndpoint$1.process(JbiEndpoint.java:46) >> at org.apache.camel.util.ProducerCache.send(ProducerCache.java:67) >> at org.apache.camel.CamelTemplate.send(CamelTemplate.java:107) >> at org.apache.camel.CamelTemplate.send(CamelTemplate.java:57) >> >> Is it possible to set some timeout while calling >> DeliveryChannel.sendSync? >> Or shall I set timeout on jms transaction manager to rollback whole >> transaction? (How to do this?) >> Should I post this on servicemix-user too? >> >> Regards, >> Piotr >> > > > > ----- > --- > Gert Vanthienen > http://www.anova.be > -- View this message in context: http://www.nabble.com/Servicemix-Camel-problem---ToJbiProcessor-hangs-tp18651622s22882p18653593.html Sent from the Camel - Users mailing list archive at Nabble.com.