On 12 January 2017 at 16:55, Lorenz Quack <[email protected]> wrote: > > > On 12/01/17 16:07, Robbie Gemmell wrote: >> >> 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. >>> >> What its meaning is that the 'null source lookup' reciever attach >> should be responded to with ab attach with a null source if there is >> no subscription, i.e there is no existing source that the broker can >> provide the details for to complete the details of the link attach for >> that named link. See an example in Figure 2.33 and 2.36 of the spec >> for refusing and recovering links, albeit for the reverse case of a >> client sending link, >> >> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568. >> > > I was referring to the part "Existing non-shared subscriber > behaviour (used for JMS 1.1)" of QPIDJMS-220 where it says: > > "[...] this is utilised by Session#unsubscribe by attaching a > receiving link using the subscription name, with a null Source, > requiring the server to perform a lookup for an existing > subscription using this link name. If none is found then the > link is refused and the client throws an exception, [...]" > > Are you saying that it is okay if the broker does not refuse the > link? That seems to contradict the above quote. From an AMQP > perspective I don't see a reason a Attach of a Receiving Link as > in this case with a null Source should fail so I would always > accept such Attachs. > >
I discussed this with lorenz, and after some digging around the AMQP spec (mainly around section 2.6.3) and discussion of the [JMS] unsubscribe process in general, I think we are good now on how these bits work. >>> Kind regards, >>> Lorenz and Alex >>> >>> >>> [1] >>> >>> https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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]
