ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: waiting for partition release question
Date Fri, 19 May 2017 11:56:39 GMT
GridCacheContinuousQueryConcurrentTest hangs from time to time on TC, so I
would first run this test on repeat locally to see how easy it is to
reproduce this.

2017-05-19 14:54 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov.sb@gmail.com>:

> How could i reproduce the issue ?
>
> пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <alkuznetsov.sb@gmail.com>:
>
> > Ok, i pick it
> >
> > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <alexey.goncharuk@gmail.com
> >:
> >
> >> Well,
> >>
> >> I don't have any clear plan for now on how to approach this issue, so
> if I
> >> were you, I would pick something else :)
> >>
> >> How about this one: https://issues.apache.org/jira/browse/IGNITE-5110?
> >> This
> >> issue bugs us on TC, it is pretty important and there is quite enough
> >> understanding on what to do.
> >>
> >> 2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov.sb@gmail.com
> >:
> >>
> >> > Now i see. So, may be i should drop the ticket and pick smth else ?
> >> >
> >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
> >> alexey.goncharuk@gmail.com>:
> >> >
> >> > > As I described before, one of the reasons behind the waiting is to
> >> switch
> >> > > primary nodes to prevent two simultaneous lock owners.
> >> > >
> >> > > Consider the following scenario:
> >> > > * Client node c1 acquired a lock L1 on node A
> >> > > * Topology changes and primary node for L1 is now new joined node
B
> >> > > * Client node c2 wants to acquire lock L1 and sends lock request to
> B
> >> > > * Node B successfully grants the lock to c2 because it does not know
> >> > about
> >> > > the previous lock
> >> > > *  Two threads now hold the lock
> >> > >
> >> > > There is a theoretical possibility of transferring lock ownership
> >> > > information during rebalancing, but this opens up whole lot new race
> >> > > conditions and failover difficulties.
> >> > >
> >> > >
> >> > > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов <somefireone@gmail.com>:
> >> > >
> >> > > > May be let second node to finish join and enter the ring, but
> start
> >> > > > rebalance after all lock will be released.
> >> > > >
> >> > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV <
> >> alkuznetsov.sb@gmail.com
> >> > >:
> >> > > >
> >> > > > > If we acquired a lock and a new node is joining cluster,
should
> it
> >> > wait
> >> > > > for
> >> > > > > lock release?
> >> > > > > May be it could proceed joining ?
> >> > > > > The question comes from my ticket
> >> > > > > https://issues.apache.org/jira/browse/IGNITE-2671
> >> > > > >
> >> > > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
> >> > > alexey.goncharuk@gmail.com
> >> > > > >:
> >> > > > >
> >> > > > > > Hi Aleksey,
> >> > > > > >
> >> > > > > > The main purpose of this method is to wait for all
ongoing
> >> updates
> >> > > > > > (transactional and atomic), initiated on the previous
topology
> >> > > version,
> >> > > > > to
> >> > > > > > finish to prevent inconsistencies during rebalancing
and to
> >> prevent
> >> > > two
> >> > > > > > different simultaneous owners of the same lock.
> >> > > > > >
> >> > > > > > We will be adding documentation pages on Apache Ignite
wiki
> >> which
> >> > > will
> >> > > > > > explain transactions mechanics in greater detail.
> >> > > > > >
> >> > > > > > Hope this helps,
> >> > > > > > AG
> >> > > > > >
> >> > > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
> >> > > alkuznetsov.sb@gmail.com
> >> > > > >:
> >> > > > > >
> >> > > > > > > Hi Igntrs!
> >> > > > > > > What is the point of waiting partition release
in the end of
> >> > > > > > > GridDhtPartitionsExchangeFuture#init() method
?
> >> > > > > > > In what scenarious do we need it ?
> >> > > > > > > --
> >> > > > > > >
> >> > > > > > > *Best Regards,*
> >> > > > > > >
> >> > > > > > > *Kuznetsov Aleksey*
> >> > > > > > >
> >> > > > > >
> >> > > > > --
> >> > > > >
> >> > > > > *Best Regards,*
> >> > > > >
> >> > > > > *Kuznetsov Aleksey*
> >> > > > >
> >> > > >
> >> > >
> >> > --
> >> >
> >> > *Best Regards,*
> >> >
> >> > *Kuznetsov Aleksey*
> >> >
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

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