[
https://issues.apache.org/activemq/browse/AMQ-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino resolved AMQ-1684.
--------------------------------
Resolution: Won't Fix
The exclusive consumer feature should satisfy your requirement. See:
http://activemq.apache.org/exclusive-consumer.html
> FIFO ordering across queue consumers
> ------------------------------------
>
> Key: AMQ-1684
> URL: https://issues.apache.org/activemq/browse/AMQ-1684
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker
> Environment: problem is not environment specific
> Reporter: Michael Ingardia
> Assignee: Hiram Chirino
>
> The JMS spec is silent on how messages are distributed across queue consumers
> when there is more than one consumer on the same queue. In many cases where
> processing of a given task is highly dependent upon the order they are
> processed ( requires FIFO processing ), a JMS queue is often used with a
> single consumer that is singled theaded. Although this does achieve FIFO
> processing it leaves handling the failure of the consumer up to the
> programmer which is a difficult task. Some JMS providers provide a way to
> specify that a message will not be delivered to a queue consumer (receive
> will block ) while a message taken from that destination has not been
> commited. What this allows for is to have multiple queue consumers hanging
> off of one queue but only one of the consumers can process a message at any
> given time. If one of the consumer processes is killed then the message is
> not commited, a time out occurs and the message is rolled back to the queue
> and the next consumer get the message and continues on its merry way. This
> makes writting a fault tolerant system much easier as you can spread
> consumers of a queue across multiple machines etc. Today ActiveMQ does not
> seem to support this capability, if more than one consumer pulls from the
> same queue the messages are load balanced across the consumers but there is
> no way to block a consumer from getting the next message thus if consumer A
> gets message 1, and one takes 10 seconds to process and consumer B gets
> message 2 immediately and it only takes 1 second to process 2, will beat one
> and cause down stream out of order problems. Handling this at the broker
> centrally is a much better solution than trying to come up with some
> distributed locking system that the consumers have to implement.
> My proposal is to add a feature to the Queue that allows for only one out
> standing message transaction, and blocks all receivers until the message is
> either commited or rolled back..
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
