OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp-bindmap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: QPID JMS JIRA-220 question


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.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]