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