Motivation

Thin clients should be able to perform Continuous Queries.

Description

Continuous query involves the following:

Cache update listener: while query is active, client receives events. Server → Client notification mechanism already exists for that (see IEP-42 Thin Client Compute).
(Optional) Remote filter

Remote Filter is a BinaryObject:

Java client can use any filter as usual, as long as the class is present on the servers.
.NET clients can use .NET filters as usual, as long as .NET platform is present on the server nodes - using PlatformContext.createContinuousQueryFilter (see ClientCacheScanQueryRequest)
Non-Java clients can use Java filters by building BinaryObjects with a Java class name and properties. Corresponding class should be registered in BinaryConfiguration.

ContinuousQueryWithTransformer is out of scope: it is a separate class, and should have a separate client operation.

Initial Query functionality is excluded intentionally, it does not bring value due to lack of guarantees - see dev list threads linked below.

Name	Code
OP_QUERY_CONTINUOUS	2006
OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION	2007

OP_QUERY_CONTINUOUS starts the query.

Existing OP_RESOURCE_CLOSE stops the query using the id provided in the OP_QUERY_CONTINUOUS response message.

Request
int	cacheId
byte	flags: standard cache flags, see ClientCacheRequest. Only KEEP_BINARY is applicable to Continuous Query. When KEEP_BINARY is set, the filter should receive key/val in binary form.
int	bufferSize (see AbstractContinuousQuery, default 1)
long	timeInterval (see AbstractContinuousQuery, default 0)
bool	includeExpired (see AbstractContinuousQuery, default false)
BinaryObject	filter
byte	filterPlatform (see ClientCacheScanQueryRequest, 1= Java, 2 = .NET) (when filter is not null)

Response
long	continuousQueryId - used to stop the query with OP_RESOURCE_CLOSE

Note: AbstractContinuousQuery.autoUnsubscribe should be always true for thin client continuous queries.

As a result of OP_QUERY_CONTINUOUS, client should expect OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION messages from the server:

int

event count

n * CacheEntryEvent

BinaryObject	key
BinaryObject	old value
BinaryObject	value
byte	event type (0 = CREATED, 1 = UPDATED, 2 = REMOVED, 3 = EXPIRED)

Flow control & backpressure: We assume no special flow control and rely on GridNioServer to handle "slow client, fast server" scenario.
Fault tolerance: Initial implementation does not provide failover in case when server node that holds the query goes down or client connection fails. It is up to specific client implementation to notify user code about the connection loss (for example, by providing special CacheEntryEvent instance that throws an exception from all members).

Key	Summary	T	Created	Updated	Due	Assignee	Reporter	P	Status	Resolution

Loading...

Refresh