activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Robinson (JIRA)" <>
Subject [jira] Commented: (AMQ-1126) The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs
Date Tue, 14 Aug 2007 13:25:27 GMT


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

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.


> The Resource Adapter ignores the JMSXGroupID when dispatching to MDBs
> ---------------------------------------------------------------------
>                 Key: AMQ-1126
>                 URL:
>             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:
> OutQueueProcessorBean@19a7266
> 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.

View raw message