You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by ALEKSEY KUZNETSOV <al...@gmail.com> on 2017/05/18 13:50:05 UTC
waiting for partition release question
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*
Re: waiting for partition release question
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
oh, i've found
пт, 19 мая 2017 г. в 15:34, ALEKSEY KUZNETSOV <al...@gmail.com>:
> Don't you remember the day the test last failed?) Im trying to find it in
> history of TC. Locally it doesn't fail
>
> пт, 19 мая 2017 г. в 14:56, Alexey Goncharuk <al...@gmail.com>:
>
>> 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 <al...@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*
>> >
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
--
*Best Regards,*
*Kuznetsov Aleksey*
Re: waiting for partition release question
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
Don't you remember the day the test last failed?) Im trying to find it in
history of TC. Locally it doesn't fail
пт, 19 мая 2017 г. в 14:56, Alexey Goncharuk <al...@gmail.com>:
> 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 <al...@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 Дмитрий Рябов <so...@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*
> >
>
--
*Best Regards,*
*Kuznetsov Aleksey*
Re: waiting for partition release question
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <al...@gmail.com>:
> How could i reproduce the issue ?
>
> пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <al...@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 Дмитрий Рябов <so...@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*
>
Re: waiting for partition release question
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
How could i reproduce the issue ?
пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <al...@gmail.com>:
> Ok, i pick it
>
> пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <al...@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 <al...@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 Дмитрий Рябов <so...@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*
Re: waiting for partition release question
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
Ok, i pick it
пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <al...@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 <al...@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 Дмитрий Рябов <so...@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*
Re: waiting for partition release question
Posted by Alexey Goncharuk <al...@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 <al...@gmail.com>:
> Now i see. So, may be i should drop the ticket and pick smth else ?
>
> пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <al...@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 Дмитрий Рябов <so...@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*
>
Re: waiting for partition release question
Posted by ALEKSEY KUZNETSOV <al...@gmail.com>.
Now i see. So, may be i should drop the ticket and pick smth else ?
пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <al...@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 Дмитрий Рябов <so...@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 <al...@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*
Re: waiting for partition release question
Posted by Alexey Goncharuk <al...@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 Дмитрий Рябов <so...@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 <al...@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*
> >
>
Re: waiting for partition release question
Posted by Дмитрий Рябов <so...@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 <al...@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 <al...@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 <al...@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*
>
Re: waiting for partition release question
Posted by ALEKSEY KUZNETSOV <al...@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 <al...@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 <al...@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*
Re: waiting for partition release question
Posted by Alexey Goncharuk <al...@gmail.com>.
Done!
2017-05-18 20:33 GMT+03:00 Denis Magda <dm...@apache.org>:
> Alex,
>
> Can you add this excellent explanation as a part of the method Javadoc?
> That will simplify a lot the life of future contributors.
>
> —
> Denis
>
> > On May 18, 2017, at 1:05 PM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
> >
> > 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 <al...@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*
> >>
>
>
Re: waiting for partition release question
Posted by Denis Magda <dm...@apache.org>.
Alex,
Can you add this excellent explanation as a part of the method Javadoc? That will simplify a lot the life of future contributors.
—
Denis
> On May 18, 2017, at 1:05 PM, Alexey Goncharuk <al...@gmail.com> wrote:
>
> 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 <al...@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*
>>
Re: waiting for partition release question
Posted by Alexey Goncharuk <al...@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 <al...@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*
>