Yes. Each connection that has a ClientID is effectively setting a namepace. As covered by the JMS spec snippet you quoted, tracking state per-name is essentially all the JMS ClientID is used for. It used to be mandatory for durable subs, but now isn't, and not specifying a ClientID is then in itself another state grouping. Accounting for the various further naming restrictions placed on the different subscription types (durable/volatile, shared/non-shared, ClientID set/not-set etc), you end up with the 5 distinct effective [sub-]spaces outlined in the JIRA, with the volatile non-shared ones being their own special almost irrelvant randomly named one as you note.
Robbie On 11 January 2017 at 10:21, Lorenz Quack <[email protected]> wrote: > Hello again, > > Alex just pointed out to me that I missed an important part of > the JMS 2.0 spec. In chapter 8.3 it says: > A shared non-durable subscription is identified by a name > specified by the client and by the client identifier if set. > I take that to mean that each client Id should have their own > separate namespace. Maybe that is what was meant in QPIDJMS-220? > > In this case I retract my previous proposal and just propose a > clarification to QPIDJMS-220: > * Each clientId creates their own namespace > * If no clientId is set this is treated like a separate > anonymous namespace > * Within each of those namespaces there exists the following > sub-namespaces: > * Durable (shared + non-shared) with durable, non-share > requiring a clientId > * Volatile shared > * Volatile non-shared are somewhat special in that they have a > randomly assigned name so they should never conflict with > anything > > > Kind regards, > Lorenz > > > > On 11/01/17 08:51, Lorenz Quack wrote: >> >> Hello, >> >> Sorry for the slightly lengthy email. >> >> tl;dr: I propose to change to the way JMS 2.0 subscriptions are >> treated in the face of the (non-)existence of a clientId as >> compared to what is outlined in QPIDJMS-220. >> >> >> Introduction: >> ============= >> I am working on adding support for JMS 2.0 shared subscriptions >> [1] to the Qpid Broker for Java using the mechanisms outlined in >> QPIDJMS-220 [2]. >> >> In QPIDJMS-220 it is outlined that there are essentially 5 >> disjunct subscription namespaces: >> * durable, shared and non-shared, with clientId >> * durable, shared, without clientId >> * volatile, shared, with clientId >> * volatile, shared, without clientId >> * volatile, non-shared, with and without clientId >> while durable, non-shared, without clientId being disallowed by >> the spec. >> >> While I think this is spec compliant I find it unintuitive and >> would like to discuss a different partitioning that, according to >> my interpretation of the spec, is also compliant. >> >> >> Proposal: >> ========= >> The difference essentially comes down to the treatment of the >> clientId. To me the clientId is like a namespace and not >> specifying it gives you access to an anonymous namespace (what >> QPIDJMS-220 calls "global"). In this it should be treated no >> different from other named namespaces resulting in the following >> partitioning: >> * durable, shared and non-shared, regardless of clientId >> * volatile, shared, regardless of clientId >> * volatile, non-shared, regardless of clientId >> with durable, non-shared, without clientId being disallowed by >> the spec. >> >> >> Relevant parts of the Specification: >> ==================================== >> From JMS 2.0 Section 8.3.2 Shared non-durable subscriptions: >> There is no restriction to prevent a shared non-durable >> subscription and a durable subscription having the same name. Such >> subscriptions would be completely separate. >> >> From JMS 2.0 Section 6.1.3 Client identifier: >> The purpose of client identifier is to associate a connection and >> its objects with a state maintained on behalf of the client by a >> provider. By definition, the client state identified by a client >> identifier can be ‘in use’ by only one client at a time. A JMS >> provider must prevent concurrently executing clients from using >> it. >> This prevention may take the form of a JMSException being thrown >> when such use is attempted; it may result in the offending client >> being blocked; or some other solution. A JMS provider must ensure >> that such attempted ‘sharing’ of an individual client state does >> not result in messages being lost or doubly processed. >> >> >> Discussion: >> =========== >> As mentioned above I think both schemes are spec compliant. The >> difference is how they prevent concurrently executing clients from >> using each others state. Section 6.1.3 allows the prevention to take >> the form of a JMSException (my proposal) or "some other solution" >> (QPIDJMS-220, a.k.a. separate namespaces). >> >> The reason for this I proposal is that I think it is a more natural >> and intuitive partitioning with easier to understand rules. >> For example, if a client with ID "foo" has a shared subscription >> called "mysub" a client with ID "bar" would be prevented from also >> creating a subscription of the name while a client without ID would be >> allowed to do this under the QPIDJMS-220 scheme. Under my proposed >> scheme both, the "bar" client and the anonymous client, would be >> prevented from creating the subscription. >> Admittedly, it also makes my life as an implementor easier. >> >> Is there a use-case or rational for the schema proposed in QPIDJMS-220 >> that I am not aware of? >> >> >> >> Kind regards, >> Lorenz >> >> [1] Chapters 8.3 and 6.1.2 of the JMS 2.0 specification >> [2] https://issues.apache.org/jira/browse/QPIDJMS-220 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
