Re: [amqp-bindmap] QPID JMS JIRA-220 question

[Robbie Gemmell <rgemmell@redhat.com>]

Yes, non-named non-durable subscriptions can be considered topic scoped. They obviously have no name to be scoped in any other fashion. I have largely ignored these, as they essentially 'dont exist' beyond the concept, its just attaching to the topic node name.

Otherwise, I disagree with your reading. I think you are taking that the createFoo methods pass a Topic to mean that the names are per-topic, when that is not stated anywhere and is often contradicted in statements either by omission or saying the opposite. The createFoo methods are just giving the topic they wish to consume from at this time, which may or may not be a topic the named subscription may or may not already exist using.

* No topic is specified when unsubscribing explicitly, since the subcription name is not scoped per topic, passes only the subscription name: https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#unsubscribe-java.lang.String-

* Non-shared durable sub use (requires a ClientID) refuses creation of a subscriber if the sub name is in use by an active subscriber on any topic, or destroys the existing subscription with the sub name if the topic changes and there isnt an active subscriber:

"If an unshared durable subscription already exists with the same name and client identifier, and there is a consumer already active (i.e. not closed) on the durable subscription, then a JMSException will be thrown.

If an unshared durable subscription already exists with the same name and client identifier but a different topic, message selector or noLocal value has been specified, and there is no consumer already active (i.e. not closed) on the durable subscription then this is equivalent to unsubscribing (deleting) the old one and creating a new one."

* Shared durable use acts similarly, except it obviously allows new subscribers with existing active subscribers in place, assuming they are also shared. The name is scoped across both shared and non-shared durable usage, on any topic. It is however distinct from non-durable subscriptions with the same name.

"A shared durable subscription is identified by a name specified by the client and by the client identifier (which may be unset). An application which subsequently wishes to create a consumer on that shared durable subscription must use the same client identifier.
If a shared durable subscription already exists with the same name and client identifier (if set), and the same topic and message selector has been specified, then this method creates a MessageConsumer on the existing shared durable subscription.
If a shared durable subscription already exists with the same name and client identifier (if set) but a different topic or message selector has been specified, and there is no consumer already active (i.e. not closed) on the durable subscription then this is equivalent to unsubscribing (deleting) the old one and creating a new one.
If a shared durable subscription already exists with the same name and client identifier (if set) but a different topic or message selector has been specified, and there is a consumer already active (i.e. not closed) on the durable subscription, then a JMSException will be thrown.
A shared durable subscription and an unshared durable subscription may not have the same name and client identifier (if set). If an unshared durable subscription already exists with the same name and client identifier (if set) then a JMSException is thrown.
There is no restriction on durable subscriptions and shared non-durable subscriptions having the same name and clientId (which may be unset). Such subscriptions would be completely separate.

Note the client cant know the name of the 'old topic' at that point (and even supposing it did it would all be very racey if done from the client side) so thats handled server-side, only one sub with a given name in the particular space at a time across all topics, for a particular client or all those without ClientID.

Similarly for shared non-durable, with the distinction noted above on namespace, and that they just dont exist if there is no active subscriber.

Most of this behaviour is long standing from JMS 1.1, with the JMS 2.0 additions fitting in with them for compatibility (shared and non shared durable subs use the same namespace, which isnt per topic) or consistency. I picked up a lot of that behaviour from stuff others did before me.

We spent a long time over years discussing how to cater for the JMS 2.0 additions, and how they might fit in with the years-old existing implementations that gave topic behaviours for the base JMS 1.1 stuff (similarly, not stuff I worked on). There were several different approaches considered including some encoding details in the address, but they all fell by the wayside for one reason or another, such as not allowing for actually implementing what the JMS spec says, being racey, or actually being far more complex than the details eventually settled on and implemented a couple of years ago now.

Robbie

On Wed, Feb 6, 2019 at 9:53 AM Clemens Vasters <clemensv@microsoft.com> wrote:

Â

By all Iâve read so far, subscriptions are always discussed in the context of a topic, specifically also in JMS 2.0 section 8.3, and each API that manages subscriptions is topic scoped:

Â

At the JMS 2.0 level,

Â

• (8.3.1) unshared, non-durable subscriptions are themselves not named, meaning theyâre anchored on the parent object, e.g. createConsumer({topic destination}), ÂÂÂ
• (8.3.2) shared, non-durable subscriptions are named and potentially qualified by a client-id, whereby the client-id constraints any further consumers of that subscription to be from the exact same client and effectively come via the same connection. All APIs for creating shared subscriptions are topic-qualified
• (8.3.3/4) Unshared and shared durable subscriptions are named and qualified by a client-id. All APIs for creating/using shared and unshared durable subscriptions are topic-qualified. The section 8.3.3. also addresses name clashes and clarifies that the subscription name and client-id combination must be not clash across shared and unshared durable subscriptions.

Â

My read here is therefore that

• All JMS subscription names are indeed topic-relative. I donât see any prescription to the contrary and no API that would suggest subscriptions to be independent.
• Client-id scoped subscription names are topic and client-id relative. With the client-id, a client claims exclusive access to the subscription and puts it onto both broker and JMS provider to enforce that uniqueness. That means that at the protocol level, the name of the subscription to be created/accessed can simply be further qualified with the client-id. It appears to be permitted for some other client node to pick up a session with the same client-id for as long as no two clients use the same session concurrently, and we have that enforcement covered in the AMQP uniqueness spec.

Â

That all is to say that I donât see the complication in the model you seem to be seeing.

Â

A subscription qualifier is made up of three parts: topic scope, name, and client-id. In the one case where the name isnât given (unshared, non-durable), the name is a temporary, unique name that might even be server-assigned. If the client-id is omitted, the subscription is sharable amongst different concurrent clients.

Â

It is true that AMQP link names must be unique, but I think it massively complicates matters here for link names to have significant structure and also control the subscription names as the BINDMAP spec suggests. And as a matter of principle it seems wrong to abuse the link name for addressing while we have a proper addressing construct in form of the âSourceâ address.

Â

During ATTACH, the âSourceâ could quite well point to a topic address and optionally the desired subscription name and the optional client-id. The address prefix must always first resolve to a topic and then the link attaches to an existing or to-be-created subscription. If the subscription name isnât given and you attach to a topic, the topic generates a subscription and provides the generated subscription name in its ATTACH response. The client-id becomes a suffix of either a generated or supplied name.

Â

Â

From: amqp-bindmap@lists.oasis-open.org <amqp-bindmap@lists.oasis-open.org> On Behalf Of Clemens Vasters
Sent: Wednesday, February 6, 2019 9:27 AM
To: Robbie Gemmell <rgemmell@redhat.com>
Cc: amqp-bindmap@lists.oasis-open.org
Subject: RE: [amqp-bindmap] QPID JMS JIRA-220 question

Â

JMS thinking of âfoo::barâ as a global identifier for a subscription doesnât contradict the broker thinking of it as a structured path.

Â

From: Robbie Gemmell <rgemmell@redhat.com>
Sent: Tuesday, February 5, 2019 7:40 PM
To: Clemens Vasters <clemensv@microsoft.com>
Cc: amqp-bindmap@lists.oasis-open.org
Subject: Re: [amqp-bindmap] QPID JMS JIRA-220 question

Â

JMS requires a subscription name be scoped to the connections ClientID (or for JMS2, also all those connections without a ClientID), and additionally sometimes whether its durable or not and shared or not. There are 5 spaces in the end I think.

Â

The subscription names are specifically not scoped to a topic within those spaces, there is only one subscription at a time with a given name (in the particular space) across all topics. If another subscriber for a given subscription name in a given space is active at the time (either on the same single connection with a specified ClientID, or across all connections without) and a second subscriber is created using the same name in that space to a different topic then an exception is to be thrown (where possible and necessary the client enforces this locally, where not its up to the server). If another subscriber is not active for the existing subscription at the time then the attempt is equivalent to unsubscribing/destroying the earlier subscription and creating a new lone subscription for the name.

Â

The clients use the link name to convey the subscription name as they also need to be able to interact with them at times armed only with a subscription name (not topic), plus you are only to have one receiver active with a given link name at once between two given containers, which lined up nicely with earlier JMS requirements and also its related enforcement of only a single connection using a specified ClientID at a time. For the newer shared subscription stuff there is then also the annoying suffixing stuff outlined in the JIRA to avoid using the same link name twice on a connection, as well as the other hoop jumping.

Â

Artemis does allow specifying terminus addresses with âmyAddress::myQueueâ convention when wishing to supply both an artemis address and queue name to influence some of its internal routing etc functionality. That is not used in the general 'topic address' handling behaviour which was mostly previously established across various other brokers/clients over the years. It can in some of the cases provide a simple means for non-JMS clients to achieve similar consumption behaviour, with some careful use of internal queue names.

Â

Robbie

Â

On Tue, Feb 5, 2019 at 3:58 PM Clemens Vasters <clemensv@microsoft.com> wrote:

https://issues.apache.org/jira/browse/QPIDJMS-220

Â

Since that JIRA is apparently the placeholder for what we still need to fit into the spec, Iâll cross the streams and ask about a Qpid issue here

Â

Iâd like to understand whether the subscription name that translates into the link name (âmySubscriptionNameâ in the examples) may/should in itself be scoped to a topic and whether thatâs the case in the present implementation as used with Qpid or Artemis.

Â

In our product, we treat subscriptions strictly as dependent entities of a single topic, meaning the name of a subscription is âmyTopic/subscriptions/mySubscriptionâ, whereby the infix â/subscriptions/â is a proprietary convention. Other brokers have different ways to express these relationships in a path; Artemis seems to be using âmyTopic::mySubscriptionâ.

Â

Â

PS: One issue this seems to surface irrespective of whether the subscription name is scoped, is that we might be missing a set of connection properties (that would appear to be the right scope) that we should define, and I think weâve mentioned this once in the AMQP call, that allows a broker to tell the client a bit of info about the topology model, e.g. whether the names of nodes/entities may be hierarchical, what the allowed character set for the segments is and what the path separator looks like, and also what the naming pattern for (potentially) dependent entities such as topic subscriptions looks like. At the Link level, an interesting property might be the address of the associated DLQ where rejected messages go.

Â

Â