waiting for partition release question

[voipp]

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*

[Alexey Goncharuk]

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 <[hidden email]>:

> 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*
>

[dmagda]

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 <[hidden email]> 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 <[hidden email]>:
>
>> 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*
>>

[Alexey Goncharuk]

Done!

2017-05-18 20:33 GMT+03:00 Denis Magda <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]>:
> >
> >> 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*
> >>
>
>

[voipp]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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*

[Dmitrii Ryabov]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > 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*
>

[Alexey Goncharuk]

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 Дмитрий Рябов <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]
> >:
> >
> > > 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 <[hidden email]
> >:
> > >
> > > > 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*
> >
>

[voipp]

Now i see. So, may be i should drop the ticket and pick smth else ?

пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <[hidden email]>:

> 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 Дмитрий Рябов <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > 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 <
> [hidden email]
> > >:
> > >
> > > > 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 <
> [hidden email]
> > >:
> > > >
> > > > > 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*

[Alexey Goncharuk]

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 <[hidden email]>:

> Now i see. So, may be i should drop the ticket and pick smth else ?
>
> пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <[hidden email]>:
>
> > 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 Дмитрий Рябов <[hidden email]>:
> >
> > > 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 <[hidden email]
> >:
> > >
> > > > 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 <
> > [hidden email]
> > > >:
> > > >
> > > > > 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 <
> > [hidden email]
> > > >:
> > > > >
> > > > > > 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*
>

[voipp]

Ok, i pick it

пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <[hidden email]>:

> 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 <[hidden email]>:
>
> > Now i see. So, may be i should drop the ticket and pick smth else ?
> >
> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <[hidden email]
> >:
> >
> > > 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 Дмитрий Рябов <[hidden email]>:
> > >
> > > > 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 <
> [hidden email]
> > >:
> > > >
> > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > >
> > > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > > >
> > > > > > > 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*

[voipp]

How could i reproduce the issue ?

пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <[hidden email]>:

> Ok, i pick it
>
> пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>> > Now i see. So, may be i should drop the ticket and pick smth else ?
>> >
>> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
>> [hidden email]>:
>> >
>> > > 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 Дмитрий Рябов <[hidden email]>:
>> > >
>> > > > 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 <
>> [hidden email]
>> > >:
>> > > >
>> > > > > 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 <
>> > > [hidden email]
>> > > > >:
>> > > > >
>> > > > > > 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 <
>> > > [hidden email]
>> > > > >:
>> > > > > >
>> > > > > > > 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*

[Alexey Goncharuk]

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 <[hidden email]>:

> How could i reproduce the issue ?
>
> пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <[hidden email]>:
>
> > Ok, i pick it
> >
> > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <[hidden email]
> >:
> >
> >> 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 <[hidden email]
> >:
> >>
> >> > Now i see. So, may be i should drop the ticket and pick smth else ?
> >> >
> >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
> >> [hidden email]>:
> >> >
> >> > > 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 Дмитрий Рябов <[hidden email]>:
> >> > >
> >> > > > 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 <
> >> [hidden email]
> >> > >:
> >> > > >
> >> > > > > 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 <
> >> > > [hidden email]
> >> > > > >:
> >> > > > >
> >> > > > > > 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 <
> >> > > [hidden email]
> >> > > > >:
> >> > > > > >
> >> > > > > > > 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*
>

[voipp]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > How could i reproduce the issue ?
> >
> > пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <[hidden email]
> >:
> >
> > > Ok, i pick it
> > >
> > > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <
> [hidden email]
> > >:
> > >
> > >> 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 <
> [hidden email]
> > >:
> > >>
> > >> > Now i see. So, may be i should drop the ticket and pick smth else ?
> > >> >
> > >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
> > >> [hidden email]>:
> > >> >
> > >> > > 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 Дмитрий Рябов <[hidden email]>:
> > >> > >
> > >> > > > 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 <
> > >> [hidden email]
> > >> > >:
> > >> > > >
> > >> > > > > 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 <
> > >> > > [hidden email]
> > >> > > > >:
> > >> > > > >
> > >> > > > > > 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 <
> > >> > > [hidden email]
> > >> > > > >:
> > >> > > > > >
> > >> > > > > > > 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*

[voipp]

oh, i've found

пт, 19 мая 2017 г. в 15:34, ALEKSEY KUZNETSOV <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>> > How could i reproduce the issue ?
>> >
>> > пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <[hidden email]
>> >:
>> >
>> > > Ok, i pick it
>> > >
>> > > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <
>> [hidden email]
>> > >:
>> > >
>> > >> 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 <
>> [hidden email]
>> > >:
>> > >>
>> > >> > Now i see. So, may be i should drop the ticket and pick smth else ?
>> > >> >
>> > >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
>> > >> [hidden email]>:
>> > >> >
>> > >> > > 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 Дмитрий Рябов <[hidden email]
>> >:
>> > >> > >
>> > >> > > > 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 <
>> > >> [hidden email]
>> > >> > >:
>> > >> > > >
>> > >> > > > > 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 <
>> > >> > > [hidden email]
>> > >> > > > >:
>> > >> > > > >
>> > >> > > > > > 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 <
>> > >> > > [hidden email]
>> > >> > > > >:
>> > >> > > > > >
>> > >> > > > > > > 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*