activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Ingardia (JIRA)" <j...@apache.org>
Subject [jira] Created: (AMQ-1684) FIFO ordering across queue consumers
Date Thu, 24 Apr 2008 14:38:43 GMT
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


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.


Mime
View raw message