> 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 <
[hidden email]>
> 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 <
[hidden email]>:
> >
> > > 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 <
[hidden email]>:
> > >
> > >> 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 <
[hidden email]>:
> > >>
> > >> > 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.
> > >> >
> > >>
> > >
> > >
> >
>
Locked
