For the most part topic subscriptions only ever had a single subscriber asociated with them, until at some point someone thought it would be useful to support more. Some systems can do that, others cant, others still have specific mechanisms to achieve the same effect.
This is all completely independent of the concepts of sessions and connections. You could have a single session with lots of subscribers on it, or lots of sessions with a single subscriber, but that doesnt particularly influence whether they can share a single subscription or not, the messaging system itself does. Various messaging systems now support doing that in their own way, hence my original question what you were using. In ActiveMQ 5.x its abilities are closely related to JMS 1.1, and I beleive its only method of achieving the shared subscribers effect is Virtual Destinations, effectively turning each subscriber for a given subscription into a specific queue consumer as you note. We recently mapped out a mechanism to support shared subscriptions over AMQP 1.0 such that the JMS 2.0 shared subscriptions functionlity could be supported for the Qpid JMS client. I'm only aware of 2 brokers that already implement support for the precise mechanism it uses, ActiveMQ Artemis (I think 2.x is needed) and the upcoming Qpid Broker-J 7.0.0. The Qpid C++ broker also supports a variant of shared susbcriptions over AMQP 1.0, but does not currently support the precise mechanism required by the JMS 2.0 client. You could similarly use those mechanisms from other AMQP 1.0 clients, or alternatively there may be other broker-specific mechanisms for achieving the same effect, but as far as ActiveMQ 5.x is concerned, I beleive your only option is Virtual Topics. Robbie On 11 April 2017 at 16:57, Jeremy Gooch <[email protected]> wrote: > If I understand this correctly, the limitation with regard to only a single > consumer on one topic is in order to maintain compliance with the JMS > specification. ActiveMQ's Virtual Destinations give a workaround for this > where a producer will publish to a topic as normal whilst allowing a consumer > to connect as if to a queue, thereby enabling the consumer to operate > multiple connections to increase its message consumption rate. > > The AMQP model has the concept of sessions within a connection. Is it > possible therefore to have multiple sessions within a connection against a > single subscription without using Virtual Destinations? We could then use a > client with some sort of concurrency feature to operate multiple sessions and > increase message consumption. > J. > > Jeremy Gooch http://goochgooch.co.uk > > From: Robbie Gemmell <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Tuesday, 11 April 2017, 14:49 > Subject: Re: One subscription, multiple consumers. > > With ActiveMQ 5 I think your only option would be Virtual Topics, > http://activemq.apache.org/virtual-destinations.html > > On 11 April 2017 at 13:17, Jeremy Gooch <[email protected]> wrote: >> It's... >> - ActiveMQ 5.14- Python 3 (running in Docker)- Latest version of Qpid Proton >> (installed via pip3) >> J. >> Jeremy Gooch http://goochgooch.co.uk >> >> From: Robbie Gemmell <[email protected]> >> To: "[email protected]" <[email protected]> >> Sent: Monday, 10 April 2017, 15:55 >> Subject: Re: One subscription, multiple consumers. >> >> Answers here are likely to be quite dependent on which server, and >> which version of it, that you are actually using. >> >> On 10 April 2017 at 10:06, Jeremy Gooch <[email protected]> wrote: >>> Hello, >>> Using Qpid Proton (mainly Python), I know you can have multiple consumers >>> against one queue and they operate in a race condition. >>> But can the same happen with a subscription? In other words, how do I >>> configure multiple consumers against one subscription so that messages are >>> distributed amongst them? This has come up as a requirement to support an >>> auto-scaling client, who wants to make multiple connections to a durable >>> subscription but not receive duplicate messages. >>> Thanks, >>> J. >>> >>> Jeremy Gooch http://goochgooch.co.uk >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
