On 2 November 2017 at 10:43, Gordon Sim <[email protected]> wrote: > 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.
This wasn't a goal, as JMS semantics actually preclude it, but the client defers to the server on that to a certain extent (it enforces much of the JMS stuff locally, but its not possible to cover everything itself, particularly in the global case). Much to Gordon's expectation I think, the intent was that they are accessing a shared terminus representing the subscription, in this case one which lives outside the container-id scoping used normally. That terminus/subscription then essentially being represented by a queue backing the subscription to the topic address and it being the main state. > > > 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 think you might be approaching this from a slightly different view than what Lorenz originally was. For completeness though, the JMS application can only give a subscription name, it doesn't/can't specify a particular link name directly as its not aware of that concept, the client names them. The '|suffix' bit of the name isn't the main thing Lorenz is raising I believe, but rather that the container-id associated with a particular connnection without a ClientID set may be used to create a link to access a subscription, and then that link not used again since connections without a ClientID set get a random container-id. The actual link names aren't important to that aspect, just that the container-id can change and potentially not be reused. With the queue itself being the main state this wasnt really seen as an issue, but the unsettled map is in interesting point, and an annoying one given no client (or other server) uses it currently that I can think. Need to think on it. > 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: [email protected] For additional commands, e-mail: [email protected]
