Versions Compared

Old Version 23

changes.mady.by.user Pavel Tupitsyn

Saved on

compared with

New Version 24

changes.mady.by.user Pavel Tupitsyn

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION

...

Name

Code

OP_QUERY_CONTINUOUS2006

OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION

2007

OP_QUERY_CONTINUOUS message format

Request
intcacheId
byteflags: 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.
intbufferSize (see AbstractContinuousQuery, default 1)
longtimeInterval (see AbstractContinuousQuery, default 0)
boolincludeExpired (see AbstractContinuousQuery, default false)
BinaryObjectfilter
bytefilterPlatform (see ClientCacheScanQueryRequest, 1= Java, 2 = .NET) (when filter is not null)
byteinitialQueryType (0 = NONE, 1 = SQL, 2 = SCAN)
initialQuery (when initialQueryType > 0)

when initialQueryType == 1 (SCAN)

BinaryObjectfilter
bytefilterPlatform (when filter is not null)
intpageSize
intpartition (-1 for no partition)
boollocal

when initialQueryType == 2 (SQL)

stringschema
intpageSize
stringsql
intargument count
n * Objectarguments
booldistributed joins
boollocal
boolenforce join order
boolcolocated
boollazy
longtimeout, in milliseconds


...

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

As a result of OP_QUERY_CONTINUOUS and until OP_RESOURCE_CLOSE is called, client should expect OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION messages from the server:

OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION message format

intevent count
n * CacheEntryEvent


BinaryObjectkey
BinaryObjectold value
BinaryObjectvalue
byteevent type (0 = CREATED, 1 = UPDATED, 2 = REMOVED, 3 = EXPIRED)


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).

...