oh, i've found пт, 19 мая 2017 г. в 15:34, ALEKSEY KUZNETSOV <alkuznetsov...@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 <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* > -- *Best Regards,* *Kuznetsov Aleksey*
