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.
