On 12 January 2017 at 15:21, Lorenz Quack <[email protected]> wrote: > Hello, > > Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the Qpid > Broker for Java support for JMS 2.0 shared subscriptions. > This is a follow-up from that discussion. > > We discussed that it would be helpful to have a document describing the > broker behaviour purely in AMQP 1.0 terms. > Alex and I went ahead and created such a document [1]. > We noticed a problem with unsubscribe as it is described in QPIDJMS-220. > There it is specified that unsubscription can be done with an Attach with a > null Source and that the broker should refuse the Link if it cannot find the > Queue the Link is referring to. This seems to violate the AMQP spec which > allows null Source Attachs. > Please review/comment. > > Kind regards, > Lorenz and Alex > > > [1] > https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support >
I had a look at the page and it seems good overall, some small comments: The assumption that the address will be 'exchange/binding' should perhaps also cover what happens when there is no /binding part given. I'd probably expect that to receive all messages sent on the exchange, at least assuming its of the topic type (and obviously for fanout too). With how things are specified/implemented, the client will look for the "SHARED-SUBS" connection capability first, and then if that is not offered by the server, it sets it as a desired capability on its shared subscriber links and inspects the response attach for it being offered. It probably doesnt hurt to always offer it on the link, but its not required (and in the YES / NO / NO / NO case from the table it would also not be set as desired since it isn't a shared subscription). Perhaps worth adding that the "YES / NO / YES / NO" case doesn't make much sense, as a non-durable 'global' sub that isn't shared can't actually be used 'globally', so it is as mentioned effectively the same as the regular volatile subscriber case. Non-shared, global isn't a combination I thought of actually being used. You could say this "YES / NO / YES / YES" makes more sense than above, e.g. allowing 1 'global' consumer to use it at a time, depending on the precise behaviour implied by the 'link' exclusivity policy, though again its not a combination I originally thought of as being used. The 'If queue already exists' bit of the description seems like it would need tweaked, since at last some combination of link details has to be able to [re-]attach to this durable subscription, perhaps the text means 'in use by consumer' instead of 'exists'? Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
