There is a potential for deadlock on all flushes in pools. The problem is that flush is synchronized and inside the flush the code can be delegated to listeners, that are external to IronJacamar.
If those listeners use their own synchronization system , they could require synchronization locking in themselves. If there is another thread locking the listener and at some point invoking an operation that results in a pool flush, the system could enter a deadlock state.
An example of stack trace:
Found one Java-level deadlock:
=============================
"JMSCCThreadPoolWorker-18":
  waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool),
  which is held by "JMSCCThreadPoolWorker-16"
"JMSCCThreadPoolWorker-16":
  waiting to lock monitor 0x00007f1d1c15d138 (object 0x0000000785998598, a com.ibm.mq.connector.outbound.ConnectionEventHandler),
  which is held by "JMSCCThreadPoolWorker-17"
"JMSCCThreadPoolWorker-17":
  waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool),
  which is held by "JMSCCThreadPoolWorker-16"
 
Java stack information for the threads listed above:
===================================================
"JMSCCThreadPoolWorker-18":
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322)
	- waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
	at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
	at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
	- locked <0x0000000788fe1fa0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
	at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)