On 11 January 2017 at 11:40, Lorenz Quack <[email protected]> wrote: > 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. >
Ah. I did reply, twice, they must have gone missing en route. The thread is archived at: https://lists.apache.org/thread.html/30bcbfd86af6b4a10e547f70e0d6e4b1c82052b43ff71ff95e5eec46@%3Cdev.qpid.apache.org%3E >> 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. Effectively, yes. For the JMS clients, all shared subscriptions will be marked 'global' when there is no ClientID set. >> >> 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. > Yep, I had just cross-posted as your second mail arrived. > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
