message-driven-channel-adapter stopped processing messages - spring-integration

Question

I have noticed that after few days running this stopped consuming messages from the queue with no known reason or trace, i have to restart it to continue processing.
Are there any known reasons behind this, also how to find out what happened in such cases and ways to fix it.
I am using WMQ and need to maintain transaction while processing a message. Thanks You.
<jms:message-driven-channel-adapter
acknowledge="transacted"
destination="inboundQueue"
channel="inboundChannel"
auto-startup="false"
max-concurrent-consumers="5"
transaction-manager="transactionManager"
recovery-interval="60000"/>
Also i will like to turn on debug on this consumer thread(s) to print that its trying to get a message, is there a way to do that.
EDITED*
I see that this had deadlocked, please let me know the cause and possible resolution, thanks.
"receivingTaskExecutor-12" - Thread t#961
java.lang.Thread.State: BLOCKED
at org.springframework.jms.listener.AbstractJmsListeningContainer.isRunning(AbstractJmsListeningContainer.java:348)
- waiting to lock <66a37d72> (a java.lang.Object) owned by "mqReceivingTaskExecutor-10" t#878
at org.springframework.jms.listener.DefaultMessageListenerContainer.scheduleNewInvokerIfAppropriate(DefaultMessageListenerContainer.java:715)
at org.springframework.jms.listener.DefaultMessageListenerContainer.messageReceived(DefaultMessageListenerContainer.java:692)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:317)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:243)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1102)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:996)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
Locked ownable synchronizers:
- locked <5a9e40d2> (a java.util.concurrent.ThreadPoolExecutor$Worker)
"receivingTaskExecutor-10" - Thread t#878
java.lang.Thread.State: TIMED_WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <35212499> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2081)
at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:328)
at org.springframework.integration.util.CallerBlocksPolicy.rejectedExecution(CallerBlocksPolicy.java:58)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:822)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1373)
at org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor.execute(ThreadPoolTaskExecutor.java:254)
at org.springframework.jms.listener.DefaultMessageListenerContainer.doRescheduleTask(DefaultMessageListenerContainer.java:682)
at org.springframework.jms.listener.AbstractJmsListeningContainer.rescheduleTaskIfNecessary(AbstractJmsListeningContainer.java:519)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1036)
- locked <66a37d72> (a java.lang.Object)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
Locked ownable synchronizers:
- locked <78ff22ed> (a java.util.concurrent.ThreadPoolExecutor$Worker)

Answer 1

Most likely is some problem up-stack (hung in user code somewhere). Use jstack <pid> to see what the container thread is doing when you hit this condition.