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: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
Date Mon, 06 Nov 2017 10:14:02 GMT
On 3 November 2017 at 16:58, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 1 November 2017 at 10:16, Lorenz Quack <quack.lorenz@gmail.com> wrote:
>
>> Hi,
>>
>> We noticed a potential problem with the way JMS 2.0 global shared
>> durable subscriptions are implemented in the JMS client.  The
>> implementation was designed, discussed, and implemented in QPIDJMS-220
>> [1].
>>
>> When a consumer of a subscription closes the underlying AMQP link is
>> not closed but merely detached since the closing of a subscription
>> link is used as the signal to unsubscribe the subscription.  These
>> subscription links remain on the broker until the subscription is
>> unsubscribed (detach with close=true) at which point the broker
>> discards all links associated with the subscription.
>>
>> For non-global subscriptions this does not seem to be a problem since
>> the clientId is used as the container-id and links are reused if
>> possible.
>>
>> For global subscription on the other hand the client uses a random
>> UUID associated with the connection as its own container-id.  This
>> means that on every new connection a new link is being estblished
>> rather than recovering an existing one.  Over time these subscription
>> links would accumulate on the broker until the subscription is
>> unsubscribed.
>>
>> Since shared durable subscriptions are expected to be long lived this
>> raises some concerns with regards to resource exhaustion on the
>> broker.  An application that would spin up a connection do some work
>> on a shared durable global subscription and then disconnect again
>> would be "leaking" links.
>>
>> Due to this concern we plan on disabling shared durable global
>> subscriptions for the initial v7 release of Qpid Broker-J.  There will
>> be a context variable to enable the feature.
>>
>>
> It seems to me a real shame that we are disabling this feature of JMS 2.0
> because of the fact that from an AMQP point of view the link *may* be
> resumed, but in practice, with JMS, will never be.  Would it not be better
> to have a context variable which affects the behaviour of such links to
> shared durable subscriptions such that if the context variable returns
> "true" the links are removed from the link registry at the time of
> connection closure, and if the context value is false, then the current
> behaviour is maintained.  We could then later add functionality to the
> client to specify (via some flag) the behaviour it desires (thus ultimately
> removing the need for the context variable)?
>
> -- Rob
>
>
>>
>> Thoughts, comments, discuss!
>>
>> Kind regards,
>> Lorenz
>>
>>
>> [1] https://issues.apache.org/jira/browse/QPIDJMS-220
>>

I agree that disabling-by-default one of the more useful feature
additions seems a real shame. The timing was dissapointing also.

The alternative idea for the context variable sounds good to me, as
does having the client flag its behaviour in some way.

Robbie

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


Mime
View raw message