I’m trying to integrate Camel with WebSphere. It is working fine, for all but one thing.
The scenario looks like:
JMS (WMQ) -> routing/transformation -> BEAN (which does a JPA (OpenJPA1.2/DB2) commit).
To be able to plug into WAS transaction manager and mangaed threads, I’m inserting the work manager as taskExecutor in camel:
<!-- Selected parts of the spring config -->
<tx:jta-transaction-manager/>
<bean id="wasTaskExecutor"
class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
<property name="workManagerName" value="wm/default" />
</bean>
<bean id="camelTransactionRequired" class="org.apache.camel.spring.spi.SpringTransactionPolicy" depends-on="transactionManager">
<property name="transactionManager" ref="transactionManager"/>
<property name="propagationBehaviorName" value="PROPAGATION_REQUIRED"/>
</bean>
<bean id="jms" class="org.apache.camel.component.jms.JmsComponent">
<property name="connectionFactory" ref="connectionFactory"/>
<property name="taskExecutor" ref="wasTaskExecutor"/>
<property name="transacted" value="true"/>
<property name="transactionManager" ref="transactionManager"/>
</bean>
Then a route, something like:
from("jms:queue:MY.QUEUE")
.transacted("camelTransactionRequired")
.log(..)
.bean(storeJPA);
This wasTaskExecutor bean is used in one stand alone spring message listener (same jms provider, WMQ) in the application as well with expected behaviour.
When deployed/started, ONE message can be processed this way (first log line below) – then threads starts to hang.
[5/12/12 22:14:55:890 CEST] 00000055 SystemOut O INFO routeFromBackend – Message pulled from queue to message box
[5/12/12 22:27:00:638 CEST] 00000031 ThreadMonitor W WSVR0605W: Thread “Default : 1” (0000001e) has been active for 739306 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung.
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:196)
at com.ibm.ws.util.BoundedBuffer.waitPut_(BoundedBuffer.java:214)
at com.ibm.ws.util.BoundedBuffer.put(BoundedBuffer.java:324)
at com.ibm.ws.util.ThreadPool.execute(ThreadPool.java:1296)
at com.ibm.ws.util.ThreadPool.execute(ThreadPool.java:1100)
at com.ibm.ws.asynchbeans.WorkItemImpl$PoolExecuteProxy.run(WorkItemImpl.java:198)
at com.ibm.ws.asynchbeans.WorkItemImpl.executeOnPool(WorkItemImpl.java:219)
at com.ibm.ws.asynchbeans.WorkManagerImpl.queueWorkItemForDispatch(WorkManagerImpl.java:433)
at com.ibm.ws.asynchbeans.WorkManagerImpl.schedule(WorkManagerImpl.java:1074)
at com.ibm.ws.asynchbeans.WorkManagerImpl.schedule(WorkManagerImpl.java:846)
at org.springframework.scheduling.commonj.WorkManagerTaskExecutor.execute(WorkManagerTaskExecutor.java:154)
at org.springframework.jms.listener.DefaultMessageListenerContainer.doRescheduleTask(DefaultMessageListenerContainer.java:669)
at org.springframework.jms.listener.AbstractJmsListeningContainer.resumePausedTasks(AbstractJmsListeningContainer.java:536)
at org.springframework.jms.listener.AbstractJmsListeningContainer.doStart(AbstractJmsListeningContainer.java:285)
at org.springframework.jms.listener.AbstractJmsListeningContainer.start(AbstractJmsListeningContainer.java:263)
at org.springframework.jms.listener.DefaultMessageListenerContainer.start(DefaultMessageListenerContainer.java:555)
at org.apache.camel.component.jms.JmsConsumer.startListenerContainer(JmsConsumer.java:84)
Has anyone seen this?
The thread is “hung” waiting to submit work to a full queue, and the work manager is configured to block rather than throw an error when the queue is full. To resolve the “hang”, either increase the number of threads in the work manager thread pool, or change the queue full action to be “error” rather than “wait”. Alternatively, investigate if the work items being submitted to the work manager are taking too long for some reason.