ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anmol Rattan <anmolrat...@gmail.com>
Subject Re: How to avoid the event lost in the continuous query
Date Sat, 24 Sep 2016 07:49:15 GMT
Hi Val,

As you mentioned there is no loss of events, but there could be duplicates.
For scenario, where strict time ordering is expected, getting results from
listener first (not in client control) renders events coming from initial
query as stale as listener responded earlier.e.g
Cache has 77,78
Initial query shall return 77 and 78. However any entry added to cache will
be delivered via cq listener in meantime  before 77 78 are sent by initial
query due to two different threads. So what listener receives is 79 77 78.
Now, 77 78 are of no use as client has already got latest id ( particularly
applicable for event based system).

There shall be flag to choose strict serial rendering for cq listener and
initial query.

Also, another question would be around remote filters. If server node goes
down, will the remote filter restore on server startup (if client were to
go down, it will as client is setting this up and will reset on startup)
lets make it extreme there is only one server node.

On Sep 24, 2016 5:28 AM, "Andrey Kornev" <andrewkornev@hotmail.com> wrote:

> I would advise against using the initial query for building a consistent
> view because of the way the feature is currently implemented in Ignite. The
> current API makes it impossible to establish the ordering relationship
> between the events delivered via the CQ listener and the data items
> returned by the initial query. The reason is that the CQ events and the
> initial results are delivered by different threads.
> Imagine the following sequence of events in the system:
> 1) the initial query thread reads the current value of the key K1 => V1
> and then it gets preempted
> 2) in the meantime, concurrent transaction updates K1 to V2 and the CQ
> listener gets dispatched with V2
> 3) the query thread resumes and the V1 value is returned from the query
> iterator.
> In this example, the code that is using the data coming from the initial
> query and the CQ listener ends up processing events out of order.
> The correct implementation of this feature would deliver all data to the
> same listener instance: first send the initial snapshot, followed by the
> special "end of snapshot" marked, followed by the CQ events.
> Regards
> Andrey
> ------------------------------
> *From:* vkulichenko <valentin.kulichenko@gmail.com>
> *Sent:* Friday, September 23, 2016 3:03 PM
> *To:* user@ignite.apache.org
> *Subject:* Re: How to avoid the event lost in the continuous query
> Hi,
> You can use ContinuousQuery.setInitialQuery to get the state of the cache
> at
> the moment of query execution. The results for this query will be returned
> in the cursor returned from the query() method. Note that in this case
> listener is actually registered before the initial query execution, so
> there
> will be no lost events, but duplicates are possible.
> -Val
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/How-to-avoid-the-event-lost-in-the-
> continuous-query-tp7904p7922.html
> Apache Ignite Users - How to avoid the event lost in the continuous query
> <http://apache-ignite-users.70518.x6.nabble.com/How-to-avoid-the-event-lost-in-the-continuous-query-tp7904p7922.html>
> apache-ignite-users.70518.x6.nabble.com
> How to avoid the event lost in the continuous query. Following is my test
> steps about continuous query. step 1: Start an Ignite Server by command "sh
> ignite.sh". step 2: Start an Ignite Client, it...
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

View raw message