On 3 November 2017 at 16:58, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > On 1 November 2017 at 10:16, Lorenz Quack <quack.lor...@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-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
