Agree, lets keep your fix then. Sergi
2015-09-04 9:05 GMT+03:00 Semyon Boikov <[email protected]>: > Yes, I tried this fix, TC results are good. I run queries suite 5 times and > don't see anymore failuers in queries restarts tests. > > I agree that it does not fix issue with Cache.destroy, but IMO it is not > critical and I don't want to spend time on this now. > > On Thu, Sep 3, 2015 at 10:47 PM, Sergi Vladykin <[email protected]> > wrote: > > > Did you try that fix, Semyon? > > > > I just think that switching start order may be not the safest solution, > > because it seems that the same error potentially can happen even > > for Cache.destroy. > > > > The correct solution should be to wait until all the queries currently > > running for this cache will end before actually stopping the cache. > > > > Thoughts? > > > > Sergi > > > > > > 2015-09-03 13:29 GMT+03:00 Sergi Vladykin <[email protected]>: > > > > > I think it was because caches configured on start must be able to setup > > > SQL schema, so QueryProcessor must be ready. > > > If this not true anymore, then the order can be changed. > > > > > > Sergi > > > > > > 2015-09-03 13:20 GMT+03:00 Yakov Zhdanov <[email protected]>: > > > > > >> Sam, I agree. Please try fix components start order and run tests. > > >> > > >> -- > > >> Yakov Zhdanov, Director R&D > > >> *GridGain Systems* > > >> www.gridgain.com > > >> > > >> 2015-09-03 12:40 GMT+03:00 Semyon Boikov <[email protected]>: > > >> > > >> > Does anybody remember why QueryProcessor is started before > > >> CacheProcessor? > > >> > > > >> > With this order cache processor can be stopped at the moment when > > query > > >> > request is processed, and this causes sporadic errors like NPE (I > see > > >> this > > >> > from time to time in IgniteCacheQueryNodeRestartSelfTest). > > >> > > > >> > Looks like cache processor does not depend on query processor so > start > > >> > order should be changed. > > >> > > > >> > > > > > > > > >
