THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| ID | IEP-50 |
| Author | |
| Sponsor | |
| Created |
|
| Status | DRAFT |
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 support).
- (Optional) Remote filter
- (Optional) Initial query: Sql or Scan
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(seeClientCacheScanQueryRequest) - 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.
Operation codes
Name | Code |
|---|---|
| OP_QUERY_CONTINUOUS | 2006 |
OP_QUERY_CONTINUOUS message format
| 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) | ||||||||||||||||||||||||||||||||
| byte | initialQueryType (0 = NONE, 1 = SQL, 2 = SCAN) | ||||||||||||||||||||||||||||||||
| initialQuery (when initialQueryType > 0) | when initialQueryType == 1 (SCAN)
when initialQueryType == 2 (SQL)
| ||||||||||||||||||||||||||||||||
| Response | |
|---|---|
| long | continuousQueryId |
| int | columnCount (when initial query is SQL) |
| n * string | column names (when initial query is SQL) |
Resulting continuousQueryId should be used to stop the query with OP_RESOURCE_CLOSE and (when applicable) retrieve initial query data with OP_QUERY_SCAN_CURSOR_GET_PAGE or OP_QUERY_SQL_CURSOR_GET_PAGE, respectively.
Note: AbstractContinuousQuery.autoUnsubscribe should be always true for thin client continuous queries.
Risks & Assumptions
- 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).
Discussion Links
- Dev list: http://apache-ignite-developers.2346864.n4.nabble.com/IEP-50-Thin-Client-Continuous-Queries-td48214.html
- POC: https://github.com/apache/ignite/pull/7966
Tickets
Overview
Content Tools
Apps
