oh, i've found
пт, 19 мая 2017 г. в 15:34, ALEKSEY KUZNETSOV :
> 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 :
>
>> GridCacheContinuousQueryConcurrentTest hangs from time to tim
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 :
> GridCacheContinuousQueryConcurrentTest hangs from time to time on TC, so I
> would first run this test on repeat locally to see how eas
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 :
> How could i reproduce the issue ?
>
> пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV :
>
How could i reproduce the issue ?
пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV :
> Ok, i pick it
>
> пт, 19 мая 2017 г. в 14:39, 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 ab
Ok, i pick it
пт, 19 мая 2017 г. в 14:39, 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, i
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.
Now i see. So, may be i should drop the ticket and pick smth else ?
пт, 19 мая 2017 г. в 13:20, 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 n
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
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 :
> 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 que
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 :
> Hi Aleksey,
>
> The main purpose of this
Done!
2017-05-18 20:33 GMT+03:00 Denis Magda :
> 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.goncha...@gmail.com> wrote:
>
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
> wrote:
>
> Hi Aleksey,
>
> The main purpose of this method is to wait for all ongoing updates
> (
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 docum
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*
14 matches
Mail list logo
