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.


Thoughts, comments, discuss!

Kind regards,
Lorenz


[1] https://issues.apache.org/jira/browse/QPIDJMS-220

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to