Please find the corresponding answers below:
- Yes, as long as at least one client is subscribed to, the subscription is kept.
When the last client unsubscribes, the server invokes unsubscribe() to the Data Adapter and, contextually, it discards the current snapshot.
- Yes. For the sake of precision, the "Unexpected snapshot event" warning is sent when the snapshot is complete and a new event with the snapshot flag is received.
If you send an event without the snapshot flag while the snapshot is being sent, the event implicitly terminates the snapshot and it is treated as a real-time event. This happens silently. If, after that, more events with the snapshot flag are sent, the warning is issued and the new event is considered as a real-time event. The EndOfSnapshot event would also trigger the warning in this case.
From the Server point of view, this is not important at all. All events received, regardless that they are part of the snapshot or real-time updates, concur in keeping aligned the internal shapshot.
The difference between a snapshot event and a real-time event is that the snapshot represents data that originated before the subscription whereas real-time updates originate after the subscription; and this information is sent to the client. So, when the Data Adapter messes up the snapshot, whether or not this is a problem only depends on the client application requirements. The Server just warns.
- No, the checks in 1) only regard the Server-to-Data-Adapter interaction and are independent from client activity.
When a second client subscribes, usually the Data-Adapter has finished sending the snapshot and is sending real-time updates. In this case, the preprocessor sends the snapshot cumulated internally. Any real-time update that has occurred before, has already been integrated in the internal snapshot. On the other hand, any real-time update that occurs concurrently is enqueued properly and sent to the client, as a real-time update, after the snapshot.
- The Data Adapter should not send updates after receiving unsubscribe() and before receiving subscribe().
However, since this cannot be completely prevented, such updates would be just discarded.
This case is best handled if you use the smartUpdate() call, where you specify the "handle" of the related subscribe() call. Hence, even after a subsequent call of subscribe(), a late update pertaining to the previous subscribe() can be identified and discarded.
In case you use the update() call, this check is not possible and it may happen that a late update pertaining to a previous subscribe() falls within a subsequent subscribe(). In this case it would be accepted and it could disturb the update flow.
- The only case is that in 1). The use of a cluster is not relevant, as the Server is not aware of this.
To resume:
The expected sequence is: subscribe() - snapshot phase - real-time phase - unsubscribe().
The EndOfSnapshot event terminates the snapshot phase.
Any real-time event (i.e. event without the snapshot flag) received in the snapshot phase also terminates the phase and initiates the real-time phase.
Any snapshot event received in the real-time phase is treated as real-time and triggers the "Unexpected snapshot event" warning.
An EndOfSnapshot event received in the real-time phase is ignored and also triggers the warning.
