qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: JMS 2.0 shared subs and clientId
Date Thu, 12 Jan 2017 17:48:47 GMT
On 12 January 2017 at 16:55, Lorenz Quack <quack.lorenz@gmail.com> wrote:
>
>
> On 12/01/17 16:07, Robbie Gemmell wrote:
>>
>> On 12 January 2017 at 15:21, Lorenz Quack <quack.lorenz@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.
>>>
>> 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: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message