HOLE query entry in CacheContinuousQueryPartitionRecovery

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

HOLE query entry in CacheContinuousQueryPartitionRecovery

voipp
Hi, Ignters!


We have a strange field HOLE in CacheContinuousQueryPartitionRecovery

which compared to pending events in
CacheContinuousQueryPartitionRecovery#collectEntries. And it is never
equals any entry.

Do we need it ? Or it can be removed.

--

*Best Regards,*

*Kuznetsov Aleksey*
Reply | Threaded
Open this post in threaded view
|

Re: HOLE query entry in CacheContinuousQueryPartitionRecovery

dmagda
I like the name. "Black holes" pop up first in my head :) The hole can absorb events and confine and digest them for billions of year. Sorry for off topic.


Denis


> On Sep 15, 2017, at 10:14 AM, ALEKSEY KUZNETSOV <[hidden email]> wrote:
>
> Hi, Ignters!
>
>
> We have a strange field HOLE in CacheContinuousQueryPartitionRecovery
>
> which compared to pending events in
> CacheContinuousQueryPartitionRecovery#collectEntries. And it is never
> equals any entry.
>
> Do we need it ? Or it can be removed.
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*

Reply | Threaded
Open this post in threaded view
|

Re: HOLE query entry in CacheContinuousQueryPartitionRecovery

voipp
HOLE was introduced in CacheContinuousQueryHandler.PartitionRecovery.
Ticket *IGNITE-426 Implemented failover for Continuous query.*
Then it was refactored in *Continuous queries fixes.*
After refactoring the variable is never compares to true. Probably, its a
bug.

сб, 16 сент. 2017 г. в 1:52, Denis Magda <[hidden email]>:

> I like the name. "Black holes" pop up first in my head :) The hole can
> absorb events and confine and digest them for billions of year. Sorry for
> off topic.
>
> —
> Denis
>
>
> > On Sep 15, 2017, at 10:14 AM, ALEKSEY KUZNETSOV <
> [hidden email]> wrote:
> >
> > Hi, Ignters!
> >
> >
> > We have a strange field HOLE in CacheContinuousQueryPartitionRecovery
> >
> > which compared to pending events in
> > CacheContinuousQueryPartitionRecovery#collectEntries. And it is never
> > equals any entry.
> >
> > Do we need it ? Or it can be removed.
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
> --

*Best Regards,*

*Kuznetsov Aleksey*
Reply | Threaded
Open this post in threaded view
|

Re: HOLE query entry in CacheContinuousQueryPartitionRecovery

Anton Vinogradov-2
Nikolay,

Could you please check?

On Tue, Sep 19, 2017 at 1:50 PM, ALEKSEY KUZNETSOV <[hidden email]
> wrote:

> HOLE was introduced in CacheContinuousQueryHandler.PartitionRecovery.
> Ticket *IGNITE-426 Implemented failover for Continuous query.*
> Then it was refactored in *Continuous queries fixes.*
> After refactoring the variable is never compares to true. Probably, its a
> bug.
>
> сб, 16 сент. 2017 г. в 1:52, Denis Magda <[hidden email]>:
>
> > I like the name. "Black holes" pop up first in my head :) The hole can
> > absorb events and confine and digest them for billions of year. Sorry for
> > off topic.
> >
> > —
> > Denis
> >
> >
> > > On Sep 15, 2017, at 10:14 AM, ALEKSEY KUZNETSOV <
> > [hidden email]> wrote:
> > >
> > > Hi, Ignters!
> > >
> > >
> > > We have a strange field HOLE in CacheContinuousQueryPartitionRecovery
> > >
> > > which compared to pending events in
> > > CacheContinuousQueryPartitionRecovery#collectEntries. And it is never
> > > equals any entry.
> > >
> > > Do we need it ? Or it can be removed.
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> >
> > --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>