activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (JIRA)" <>
Subject [jira] Assigned: (AMQ-1684) FIFO ordering across queue consumers
Date Thu, 24 Apr 2008 17:05:43 GMT


Hiram Chirino reassigned AMQ-1684:

    Assignee: Hiram Chirino

> FIFO ordering across queue consumers
> ------------------------------------
>                 Key: AMQ-1684
>                 URL:
>             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.

View raw message