On Tue, 2017-11-07 at 10:43 +0000, Rob Godfrey wrote: > On 7 November 2017 at 10:26, Lorenz Quack <quack.lor...@gmail.com> wrote: > > > > > On Tue, 2017-11-07 at 09:51 +0000, Robbie Gemmell wrote: > > > > > > > > > Hi Lorenz, > > > > > > This sounds/looks good to me overall, though I wonder around whether > > > the 'more than 1 left' checking + subsequent calls are racey (e.g > > > across different connections with subscribers detaching at the same > > > time) and if so about the consequences. > > > > > > Robbie > > Hi Robbie, > > > > Well spotted. It is known to be racey. > > In the worst case the last two links would unsubscribe concurrently and > > both be removed from the link registry. Upon unsubscribe the link would > > not be found in the registry and the attach would be rejected with > > "not-found". The subscription queue would remain on the broker. > > There are other races connected to shared subscriptions / link registry. > > That does not make it better but we really want to get the release out > > so we created QPID-7996 to address these issues in 7.0.1. > > > > We are going to back port the change an spin a RC2 today. > > > > > It'd be ugly as hell - but couldn't you just wrap the search for links / > link close statement in a synchronized block synchronizing on the vhost or > the link registry? > > -- Rob >
I guess. The LinkRegistry is not exposed but I just checked and there does not seem to be anything else that is synchronized on the VirtualHost so we could use that and should not be a lot of contention or potential for deadlocks. Kind regards, Lorenz --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
