[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1416) Provide complete message ordering

Fri Mar 27 20:52:22 EDT 2009

    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12459458#action_12459458 ] 

Fusayuki Minamoto commented on JBMESSAGING-1416:
------------------------------------------------

Hi Howard,

I have a requirement from the customer about "selector" limitation of you idea (03/Feb/09 05:11 AM).

>* Ordering group shouldn't be used together with message selectors and scheduled delivery. 

We guess this statement means those just change the messagin ordering.

But the customer need to use "selectors" because JBoss ESB uses selectors quite often for request-reply message pattern with queues:
http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.GA/html-single/Programmers_Guide/index.html#sect-SOA_ESB_Programmers_Guide-What_is_a_Service-ServiceInvoker

For example, a user sends requests such as req-1, req-2, req-3 then should get the reply-1, reply-2, reply-3 in order, even with selectors for the reply queue.

So the customer requires JBM keeps order of messages and doesn't throw exceptions when we even use selectors with ordering group function. 

Is that OK with you?

Regards,
Fusayuki

> Provide complete message ordering
> ---------------------------------
>
>                 Key: JBMESSAGING-1416
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1416
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>
> As per customer request we would like to introduce new functionality over and above the JMS ordering guarantees.
> The idea is that the user should be able to determine an "ordering group". This can be done by setting a reserved property on the message before sending.
> The ordering group can be pinned to the producer or just be some other arbitrary string.
> In order to guarantee strict ordering, even on rollback or in the presence of multiple consumers or with xa transactions, the queue needs to ensure that no more than one message with the value of ordering group is being delivered at any one time.
> When that message has been acked, or cancelled the next one can be delivered.
> This is of course will provide a performance penalty since we won't be able to do consumer buffering, but that's the price you pay if you want such a strict ordering guarantee.
> We can subclass our MessageQueue class to do this. The sub-classed class can maintain a map of ordering group-->boolean. Which will determine whether the queue is currently delivering any messages with that ordering group value. It will consult that map when delivering to decide whether it can deliver the next message.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira