Hi Robbie, answers are in-line.
On 11/01/17 10:24, Robbie Gemmell wrote:
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 ;)
Sorry, I am not sure what email you are talking about. I never received an email regarding this issue. Specifically, my email with subject "questions regarding QPIDJMS-220" went unanswered from my point of view. I also just checked my spam folder. Nothing. Weird.
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... [*snip*]
Yes, I wasn't aware of all the details and problems and naively assumed that the container-id was empty/null if there was no clientId. Obviously, I had not verified this. My understanding now is that it is the "global" Source capability that indicates that there is no clientId and the container-id should be ignored; at least as far as subscriptions are concerned.
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.
I think this was addressed by my second email and leads me to think that we are now in agreement. Kind regards, Lorenz
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
