On 12 January 2017 at 15:21, Lorenz Quack <quack.lor...@gmail.com> 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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to