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 <sergi.vlady...@gmail.com> 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 <sergi.vlady...@gmail.com>: > > > 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 <yzhda...@gridgain.com>: > > > >> 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 <sboi...@gridgain.com>: > >> > >> > 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. > >> > > >> > > > > >
