jsr343-experts@jms-spec.java.net

[jsr343-experts] Re: (JMS_SPEC-115) Remove the statement that portable applications should only have one consumer per queue

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Tue, 19 Feb 2013 17:50:38 +0000

On 19/02/2013 16:56, John D. Ament wrote:
> While technically feasible, I would consider it poor practice to have multiple consumers on a queue, unless they were
> using selectors to separate content.

I think the main reason for having multiple consumers on a queue would be allow multiple Java SE applications, or
multiple threads within the same Java SE application, to share the work of processing the messages on a queue.

Nigel

>
> On Tue, Feb 19, 2013 at 11: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).
>
>
>