anonymous wrote : | You mean JBoss MQ specific? JBoss Messaging doesn't have these properties. | I wondered about this. Based on this, the JMSXDeliveryCount will be consulted first and then the cached id in attempting to determine if the message should be sent to the DLQ. Effectively with JBM, no JBoss specific properties are consulted. anonymous wrote : | If a RuntimeException is thrown from onMessage and the session is transacted it is ignored as per JMS spec and delivery of the next message continues. | anonymous wrote : | Transacted Session - the next message for the listener is delivered. The client | can either commit or roll back the session (in other words, a | RuntimeException does not automatically rollback the session). | This is what we do, with the default behavior being that a rollback occurs. This can be altered via an ActivationSpec property to simply commit the message in the case of a RuntimeException when the transaction attribute of the MDB is BMT or CMT with NOT_SUPPORTED. CMT/REQUIRED is always rolledback and redelivered as per the EJB spec. anonymous wrote : | Perhaps we should have an option to turn off JCA dlq functionality if we know the provider supports its own? Should this be the default? | You can already do this it's a simple property (useDLQ) of the JMSActivationSpec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986911#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...