[jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-527) JBoss Messaging should support JMSXDeliveryCount

[ http://jira.jboss.com/jira/browse/JBMESSAGING-527?page=all ] Ovidiu Feodorov updated JBMESSAGING-527: ---------------------------------------- Description: Joel: Here is an excerpt from theserverside which sums up the retry concept within a transaction well: http://www.theserverside.com/tt/articles/content/JMSArchitecture/JMSAppli... For point-to-point messaging, when a transaction reads a message, the message becomes available to the transaction, but does not get physically removed from the destination at that time; instead, the messaging system leaves the message on the destination but does not allow other transactions to see it. When the transaction commits, the message is completely removed from the destination; however, if the transaction rolls back, the message stays on the destination and is now allowed to be read by other transactions. Ovidiu: Right. This is how Messaging does it. Though, to be 100% technically accurate, what it does is actually transacting acknowledgments. The message becomes available to the transaction, and it's the acknowledgment that is sent back to the channel in a transactional context. The acknowledgment is delivered to the channel (and the message removed from the channel) only when transaction commits. Joel: This allows for a powerful feature called replay. Replay is the ability to retry the transaction after a rollback. The danger here is you can get caught in an infinite loop trying to replay the transaction. However, JMS systems can make use of the re-delivered count field on the message descriptor. Here, one can determine how many times the message has been re-delivered to a consumer and allow one to stop processing the message. Ovidiu: We're actually not supporting JMSXDeliveryCount yet, you're right here. The spec says it's optional. If it's important for you, just log a JIRA feature request, and we'll do it, subject to resource availability. Joel: Thanks Ovidiu, JMSXDeliveryCount is definitely a very high priority for us. With the rapid growing adoption of MDP use I imagine that I will be something that is also in high demand for the community at large. Furthermore, most JMS vendors support this behavior, so it probably makes sense for JBoss to put it on the roadmap. was: Joel: Here is an excerpt from theserverside which sums up the retry concept within a transaction well: http://www.theserverside.com/tt/articles/content/JMSArchitecture/JMSAppli... For point-to-point messaging, when a transaction reads a message, the message becomes available to the transaction, but does not get physically removed from the destination at that time; instead, the messaging system leaves the message on the destination but does not allow other transactions to see it. When the transaction commits, the message is completely removed from the destination; however, if the transaction rolls back, the message stays on the destination and is now allowed to be read by other transactions. Ovidiu: Right. This is what Messaging does it. Though, to be 100% technically accurate, what it does is actually transacting acknowledgments. The message becomes available to the transaction, and it's the acknowledgment that is sent back to the channel in a transactional context. The acknowledgment is delivered to the channel (and the message removed from the channel) only when transaction commits. This allows for a powerful feature called replay. Replay is the ability to retry the transaction after a rollback. The danger here is you can get caught in an infinite loop trying to replay the transaction. However, JMS systems can make use of the re-delivered count field on the message descriptor. Here, one can determine how many times the message has been re-delivered to a consumer and allow one to stop processing the message. We're actually not supporting JMSXDeliveryCount yet, you're right here. The spec says it's optional. If it's important for you, just log a JIRA feature request, and we'll do it, subject to resource availability :). Joel: Thanks Ovidiu, JMSXDeliveryCount is definitely a very high priority for us. With the rapid growing adoption of MDP use I imagine that I will be something that is also in high demand for the community at large. Furthermore, most JMS vendors support this behavior, so it probably makes sense for JBoss to put it on the roadmap. -- 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