On 19/02/2013 17:25, Clebert Suconic wrote:
> I didn't even know you didn't need to support multiple consumers on a single queue... good catch there!
>
> also, in regard to this:
>
> >>>> "but that JMS does not define how messages from a queue are distributed amongst multiple consumers"...
>
> it's good that you put this way, because that's a configurable behaviour in most JMS providers I know... such as how the
> system will prefetch and execute load balancing.
Agreed. I took the wording from JMS 1.1 section 5.8 "QueueReceiver":
"Although it is possible to have two sessions with a QueueReceiver for the same queue, JMS does not define how messages
are distributed between the QueueReceivers."
Curiously this section makes no mention of such a useage being non-portable. (In the JMS 2.0 draft this was moved to
section 8.2.1)
Under the umbrella of this issue I'd like to clarify a number of related issues which have got somewhat mixed up:
* Although the title of section 4.4.9 is "multiple sessions" it actually talks about multiple consumers
(TopicSubscribers and QueueReceivers) which is not the same thing.
* It seems to be talking about multiple consumers within the same JVM without explicitly mentioning that the same
semantics apply with multiple consumers in multiple JVMs.
* For topics, it confuses the concepts of "subscription" (a set of messages in the JMS provider) and "subscriber" (a
consumer object in the client). I think in general the new spec is much clearer (there's a whole new section 8.3 about
this), but not in this particular section.
* For queues (and as described in this issue) the statement that portable applications must not create more than one
consumer on a queue is obsolete and can be removed. A general statement is needed that states that a queue can have
multiple consumers, and which describes the basic semantics that only one consumer gets a given message,
* For both queues and topics a statement is needed that JMS does not define how messages are distributed amongst
multiple consumers on the same queue or shared subscription (i.e. there are no specific requirements for balancing).
I think what is needed is a new overview of queue and topic semantics towards the beginning of the spec. I'll work on
some text and circulate it for comments.
Nigel
>
>
> On Tue, Feb 19, 2013 at 10:48 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> Whilst reviewing the draft spec I came across this issue. Although I hope this s simply a recognition of current
> practice it represents a spec change and so is worth highlighting more formally and asking for views.
>
> If possible I'd like to include this in JMS 2.0.
>
> -------- Original Message --------
> http://java.net/jira/browse/__JMS_SPEC-115 <http://java.net/jira/browse/JMS_SPEC-115>
> Remove the statement that portable applications should only have one consumer per queue
>
> The JMS 1.1 specification, in section 4.4.9 "Multiple Sessions" states that
>
> For PTP, JMS does not specify the semantics of concurrent QueueReceivers for
> the same Queue; however, JMS does not prohibit a provider from supporting
> this. Therefore, message delivery to multiple QueueReceivers will depend on the
> JMS provider's implementation. Applications that depend on delivery to
> multiple QueueReceivers are not portable
>
> This means that a JMS provider is not required to support multiple consumers on the same queue, and that although
> JMS providers are allowed to do so, any application which depends on this is not portable.
>
> I think that statement is obsolete now that all modern JMS providers allow multiple consumers on a queue. It is also
> anomalous now that JMS 2.0 requires shared subscriptions to allow multiple consumers.
>
> It is therefore proposed that the section above be reworded to state that a queue may have multiple consumers, but
> that JMS does not define how messages from a queue are distributed amongst multiple consumers (i.e. there is no
> requirement for load-balancing etc).
>
>
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suconic@jboss.com
> http://clebertsuconic.blogspot.com