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.