On 02/11/17 08:56, Lorenz Quack wrote:
On Wed, 2017-11-01 at 12:10 +0000, Gordon Sim wrote:
On 01/11/17 10:16, Lorenz Quack wrote:
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.
I may of be misunderstanding the issue, but my understanding was that
the portion of the link name after (and including) the '|', should be
ignored in identifying the shared terminus.
There would be no need to store and link specific information for a link
from such a global, shared subscription once a link is no longer active.
Hi Gordon,
What about link specific state like the unsettled map?
To me it seems we would need to preserve that.
On a side note, in the broker-j implementation the termini are actually
not shared. This means that you can, for example, use different filters
on different subscribers of a shared subscription.
Yes, if you want to offer link specific features on a durable shared
subscription, and retain these even when the links are inactive, then I
agree you would need a way of identifying links separately from the
subscription.
The client would then need to reuse the same qualifier following the '|'
for the same link. I don't know JMS well enough; where would that
information come from? I.e. how would an application indicate a specific
link on a shared, global durable subscription?
I guess the problem is that there is no way of knowing whether the
broker is expected to track the link names in full or not, or from the
clients pov whether the broker is going to track those.
For cases where the terminus is not shared, i.e. where the terminus is
not the subscription, I think perhaps it would be clearer to have the
subscription identified in the source address.
Probably need Robbie's/Rob's input on this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
