Hi Lorenz, Your timing couldn't be better/worse hehe. As you hadnt replied following the related mail a month or so ago, I didn't think there was more to discuss on this. I had actually planned to start doing the release right about now...I almost got to it yesterday, alas ;)
I am unclear from the text exactly how you are proposing to access this 'anonymous namespace'. The JMS ClientID is being carried using the AMQP connection container-id, which is a mandatory field to specify, so a container-id must be given. Did you mean for example to have all JMS clients without a ClientID use some fixed value as their container ID (e.g. empty string, which as rather an aside, could clash with ideas such as those in https://issues.apache.org/jira/browse/QPID-7605)? Assuming that is the case... Using a fixed container-id for all non-ClientID-using JMS connections was actually the original idea when we were first thought on this in years past (there have been *many* variations before arriving at this one). In the end we elected not to pursue that as it has some issues, especially when interacting with the shared subscriptions stuff. For example: - If multiple connections are using a fixed container-id, each needs to name links they produce uniquely or risk stepping on another connections toes by stealing its links (or just generally violating the spec) given they share a container-id. This makes it likely that over time we would be unable to reuse the same names for a given durable subscription (without the client somehow persisting it), creating new link names link over time and effectively forgetting about the old ones. - The link naming issue makes JMS durable subscription unsubscribe (which need be based on only the link name) similarly a problem. - It forces non-JMS clients to adjust their container naming to use the same mechanism and share such subscriptions with such connections. I actually see no reason that non-JMS clients shouldn't be able to share subscriptions across container-id's, if they choose to (the subscriptions must be marked for such to be possible, so it isnt true that any client can access state they should not be able to) i.e have their own container-scoped [shared] subscriptions but also access subscriptions shared across any container. I consider the fact JMS 2.0 forces you use two different connections in that scenario to be a poor aspect of the spec additions, it was actually one of the very first things that hit me when I read the JMS 2 spec originally. - It just seems nicer for connections to have their own container-id's than all using the same one, especially given some things use the container for naming as well. - I think there were other reasons, but there have been so many minute details with the various ideas gone through before settling on this, that I can honestly no longer remember many of them. Robbie Actually, re-reading the last section, I appear to have misinterpreted it on my first read through and so did not address it before considering any the above. I'll address is separetely now: "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" That would violate the JMS spec. Clients with different ClientIDs are allowed to use the same subscription names at the same time. "while a client without ID would be allowed to do this under the QPIDJMS-220 scheme." As they should. By not having a ClientID, they are not using the "foo" or "bar" ID and so should be allowed to create a subscription named "mysub" atthe same time, which only other connections without a ClientID can use. On 11 January 2017 at 08:51, Lorenz Quack <[email protected]> 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]
