[ http://jira.jboss.com/jira/browse/JBAS-4438?page=all ] Tim Fox updated JBAS-4438: -------------------------- Description: Some JMS providers e.g. JBoss Messaging implement an optional redelivery delay between successive deliveries of the same message after rollbacks due to a failure. This is a nice feature and is designed to prevent thrashing which can consume CPU when failure in delivery occurs frequently. When using such providers with JBoss AS MDBs, using either the JMSContainerIvoker or JCA 1.5 inflow, this fetaure is unusable since the MDB container wraps the onMessage method of the MDB and catches any exceptions thrown by the MDB and handles redlivery itself. Consequently the provider does not have a chance to execute any redelivery delay logic. It would be great for the MDB container to implement redelivery delay itself. was: Some JMS providers e.g. JBoss Messaging implement an optional redelivery delay between successive deliveries of the same message after rollbacks due to a failover. This is a nice feature and is designed to prevent thrashing which can consume CPU when failure in delivery occurs frequently. When using such providers with JBoss AS MDBs, using either the JMSContainerIvoker or JCA 1.5 inflow, this fetaure is unusable since the MDB container wraps the onMessage method of the MDB and catches any exceptions thrown by the MDB and handles redlivery itself. Consequently the provider does not have a chance to execute any redelivery delay logic. It would be great for the MDB container to implement redelivery delay itself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4438?page=comments#action_12363293 ] Tim Fox commented on JBAS-4438: ------------------------------- Please don't shoot the messenger! I filed this in response to Weston Price's suggestion to file a JIRA for it (see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=105141) If the container handles redelivery by NACking back to the destination, then I can see this doesn't actually make a lot of sense, although could still be useful for JMS providers that don't implement any kind of redelivery delay themselves. Feel free to reject it. (Aside: Is NACKing back to the queue really the correct way to handle rollback? The JMS spec says that session rollback should cause *recovery* of the session (Sec 4.4.7). Session recovery (Sec. 4.4.11) is supposed to stop and restart delivery of the last unacknowledged in that session. If you NACK on rollback then the message will go back to the queue and if there is *another* session consuming from the same queue, then the other session may receive the NACKed message, which would be contrary to the JMS spec which is pretty clear the message should be delivered back to the same session. For this reason, JBoss Messaging (unlike JBossMQ) always triggers session recovery (not NACK) on rollback, to ensure the correct session gets the rolled back messages.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira