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

[Robbie Gemmell <rgemmell@redhat.com>]

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.

Â

Â