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