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.
On Tue, Feb 19, 2013 at 10:48 AM, Nigel Deakin <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