[ 
https://issues.apache.org/activemq/browse/AMQ-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39929
 ] 

John Robinson commented on AMQ-1126:
------------------------------------

Page 31, section 3.5.9 of the JMS Specification states:

JMSXGroupID and JMSXGroupSeq are standard properties clients should use if
they want to group messages. All providers must support them.

So I guess the real question is, what does it mean to support it?

I agree that the MDB container is the listener, and that it is free to dispatch 
messages to to which ever MDB instance it chooses.

However, what I think is broken is that it is dispatching them in parallel.  
That is, it should, in my opinion, be handing out one message at a time, and 
not handing out another one until the first message is acknowledged, or its 
transaction is committed, for example.  In other words, it should finish one 
before sending another.

If it does not do this, then grouping has no semantic meaning or purpose with 
MDBs, at least that I can divine.

I would further point out that, in my opinion, the container is free to 
dispatch any one message, without respect to order, so long as the sequence 
number was not set.  If the sequence number and the group number are set, then 
the container should be handing a single MDB a single message for that group in 
the order defined by the sequence number.

Right now, when grouping and sequence numbers are used with MDBs, the messages 
are dispatched in sequence, but because the container does not wait for the 
first one to finish before dispatching the second one, the messages end up 
being processed simultaneously, and thread/execution priority determines which 
one finish first.  

For example, if you have a message that takes a long time to process (call it 
message A) and a message that takes a short amount of time to process (call it 
message B), and you group them and sequence them so that A is first and B is 
second, then with MDBs it is quite likely that B (the shorter one) will finish 
first.  I think, based on my understanding, that the container should dispatch 
message A, wait until it is 'complete', and then dispatch message B.

Whether they go to the same, or a different, MDB instances is really moot, and 
shouldn't matter a whit.

In my opinion part of the problem is that the spec is very vague on what, 
exactly, is meant by 'support' with respect to these two attributes.

I would love to hear from others on this subject.

-John


> The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs
> ---------------------------------------------------------------------
>
>                 Key: AMQ-1126
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1126
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JCA Container
>    Affects Versions: 4.0.1
>         Environment: Java 1.4.2_08
> JBoss 4.0.4
> ActiveMQ 4.0.1
>            Reporter: John Robinson
>
> Integrate AMQ into JBoss using the data source, and resource adapter.  Create 
> an outbound queue and an MDB with a pool size of 100.  Dispatch several 
> messages to the outbound queue, setting the JMSXGroupID property on the 
> message to be the same value each time.  In the MDB's onMessage method print 
> out the MDBs toString (don't override toString) and you should see something 
> that looks like:
> [EMAIL PROTECTED]
> Observe two things:
> a) Many messages are processed in parallel
> b) Many different values will occur after the @ in the above message, 
> denoting that more than on MDB instance is being handed messages.
> The correct behavior would be to dispatch messages with the same group id to 
> the same MDB instance in sequence.  This would allow messages from different 
> groups to be processed in parallel, but messages in any one group would be 
> processed serially, in the order in which they were placed into the queue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to