The message is left in the queue when a non-recoverable exception occurs. Currently only StaleStateException and LockAcquisitionException are treated as recoverable. System exceptions, such a connection acquisition problem, need administrative action before proceeding, so they are not recovered automatically.
After you fix the problem you would recover the affected process manually. Neither the console nor a simple API call currently allow you to do so for individual process instances, but you can do it for all instances by redeploying the .ear. Re: jmsConnection.stop(), there is a feature documented in the javadoc for that method which may explain the behavior: anonymous wrote : If message listeners are running when stop is invoked, the stop call must wait until all of them have returned before it may return. While these message listeners are completing, they must have the full services of the connection available to them. If no reception is in course when you invoke the method and still delivery does not stop, then there is an probably an anomaly in the implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153054#4153054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153054 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
