Data Subscriptions: Consumption API Overview
In this page:
Subscription worker generation
Subscription worker generation is accessible through the
Subscriptions Property, of type
SubscriptionWorker<dynamic> GetSubscriptionWorker(string subscriptionName, string database = null); SubscriptionWorker<dynamic> GetSubscriptionWorker(SubscriptionWorkerOptions options, string database = null); SubscriptionWorker<T> GetSubscriptionWorker<T>(string subscriptionName, string database = null) where T : class; SubscriptionWorker<T> GetSubscriptionWorker<T>(SubscriptionWorkerOptions options, string database = null) where T : class;
||The subscription's name. This parameter appears in more simple overloads allowing to start processing without creating a
||Contains subscription worker, affecting the interaction of the specific worker with the subscription, but does not affect the subscription's definition|
||Name of the database to look for the data subscription. If
||A created data subscription worker. When returned, the worker is Idle and it will start working only when the
The only mandatory parameter for SubscriptionWorkerOptions creation is the subscription's name.
||Returns the subscription name passed to the constructor. This name will be used by the server side to identify the subscription in question.|
||Time to wait before reconnecting, in the case of non-aborting failure during the subscription processing. Default: 5 seconds.|
||If true, will not abort subscription processing if client code, passed to the
|Sets the way the server will treat current and/or other clients when they will try to connect. See Workers interplay. Default:
||Maximum amount of documents that the server will try sending in a batch. If the server will not find "enough" documents, it won't wait and send the amount it found. Default: 4096.|
||If true, it performs an "ad-hoc" operation that processes all possible documents, until the server can't find any new documents to send. At that moment, the task returned by the
||The size in bytes of the TCP socket buffer used for sending data.
Default: 32,768 (32 KiB)
||The size in bytes of the TCP socket buffer used for receiving data.
Default: 32,768 (32 KiB)
Running subscription worker
After receiving a subscription worker, the subscription worker is still not processing any documents. SubscriptionWorker's
Run function allows you to start processing worker operations.
Run function receives the client-side code as a delegate that will process the received batches:
Task Run(Action<SubscriptionBatch<T>> processDocuments, CancellationToken ct = default(CancellationToken)); Task Run(Func<SubscriptionBatch<T>, Task> processDocuments, CancellationToken ct = default(CancellationToken));
||Delegate for sync batches processing|
||Delegate for async batches processing|
||Cancellation token used in order to halt the worker operation|
||Task that is alive as long as the subscription worker is processing or tries processing. If the processing is aborted, the task exits with an exception|
||Batch's items list.|
||Amount of items in the batch.|
|Method Signature||Return value||Description|
||New document session, that tracks all items and included items of the current batch.|
||New asynchronous document session, that tracks all items and included items of the current batch.|
Subscription Session characteristics
Session will be created by the same document store that created the worker, therefore will receive the same configurations as any other session created by the store.
However, in order to maintain consistency, the session will address the same server that the batch was received from.
It won't try to fail over to another server. It might also fail if the subscription worker changes the node it communicates with.
Such event could happen if the subscription worker starts again to address its original node after a fallback occurrence.
If such failure occurs, the subscription processing will be stopped, and will have to be restarted, as shown here
if T is
BlittableJsonReaderObject, no deserialization will take place
||Current batch item.|
||Message of the exception thrown during current document processing in the server side.|
||Current batch item's underlying document ID.|
||Current batch item's underlying document change vector of the current document.|
||Current batch item before serialization to
||Current batch item's underlying document metadata.|
||Current batch item's underlying metadata values.|
Metadata values outside of the document processing delegate are not supported
|Method Signature||Return Type||Description|
||Aborts subscription worker operation ungracefully by waiting for the task returned by the
||Async version of
||Aborts the subscription worker, but allows deciding whether to wait for the
||Async version of
|Run (multiple overloads)||
||Starts the subscription worker work of processing batches, receiving the batch processing delegates (see above).|
||Event that is risen after each the server acknowledges batch processing progress.|
||Event that is fired when the subscription worker tries to reconnect to the server after a failure. The event receives as a parameter the exception that interrupted the processing.|
||Event that is fired after the subscription worker was disposed.|
||The batch process which was acknowledged|
||Task for which the worker will wait for the event processing to be finished (for async functions etc.)|
||Returns current processing RavenDB server's node tag.|
||Returns processed subscription's name.|