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.
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.
|