0

When subscribing to real-time notifications, I go through the normal handshake, subscribe, connect flow. Once the connection returns with events, I reconnect and wait for the next response to return. My question is: If events are generated the first response and the next reconnect, could they be lost?

As an example: A synchronous application which processes returned response data after it returns and only reconnects once the data processing has finished could cause a significant delay between the response and the next reconnect. Are the cumulocity events generated during that delay buffered in the real-time queue for that particular client id or are they just lost?

Another possible example is when the client ID is no longer valid (this seems to happen every day at midnight), I have to resubscribe, causing a period of time during which no one is subscribed.

Davis Kirkendall
  • 184
  • 6

1 Answers1

0

The client ID that you receive when handshaking is connected to a queue on the server side. That queue keeps all notifications that you are not able to receive until the next connect. It delivers them when you reconnect. (Try it out with Postman: After a connect returns, send a couple of events, then connect again. You will notice that you will get all events at once.)

However, as you noticed, the queue is not kept forever. If you are not able to reconnect within two hours (I believe), the queue is thrown away in order to not block server resources. This is what you noticed. In that case, you need to query the database to determine any missed events (e.g., poll any operations in pending state from devices).

André
  • 668
  • 6
  • 11
  • So the queue is not automatically thrown away when the date changes/at midnight, but only when the last connect is to long ago? – Davis Kirkendall Mar 10 '16 at 07:59
  • Yes, that should be at least the behaviour. Did you experience this? Maybe there is a bug in cometd? I would be happy about any reproducers so that we can fix it potentially. – André Mar 15 '16 at 20:30