Piotr,
My guess was that the Camel component's thread pool was running out of
threads. If it is, it wouldn't be showing in any of the components'
stacktraces -- they would just be polling the DeliveryChannel for work
like the ones you posted. Does your to("jbi:...") ever end up in another
Camel routes (e.g. in one that starts with from("jbi:..." )-- if not, we
can forget about the thread pool as a cause for your problems alltogether...
You should be able to set the transaction timeout through the JMS
endpoint as document on http://activemq.apache.org/camel/jms.html
Regards,
Gert
Piotr Jagielski wrote:
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
