qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Accumulation of Links from global shared durable subscriptions (JMS 2.0)
Date Tue, 07 Nov 2017 10:43:33 GMT
On 7 November 2017 at 10:26, Lorenz Quack <quack.lorenz@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


> Kind regards,
> Lorenz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message