ETA Hot-Standby resiliency

karun.matharu

Some of this has been touched upon in previous questions but I couldn't find an answer for this --

I am looking to build a hot-standby feed handler with the Elektron ETA in C++ between an A and B feeds where feed switching can happen without any dropped messages and without any delay for initiating or connecting to the other feed should one go down. As such, I'll run both feeds simultaneously but to combine them, I need to be able to uniquely identify each message. Unfortunately, to my knowledge, none of the parameters in the updates I receive can uniquely identify each message -- for example TRADE_ID only uniquely identifies the trade messages and SEQNUM isn't actually a sequence number because sequential updates can have the same SEQNUM.

Do you know of a method or parameter within ETA that permits uniquely identifying each update? or alternatively a way around this to be able to create a Hot-Standby handler as such?

Thanks

Gurpreet

Hi @karun.matharu,

I guess the summary answer is that we don't offer hot standby at the application layer. The infrastructure components offer this ability and this is how they do it.

Hot standby depends on the close timing of update to each ADH, and the source provider must offer Group Status and Commlink status messages - which are RSSL only. By default the ADH matches updates using memory comparisons - which does not support conflation. If hot standby is required with conflated data, then a sequence number based update matching is done.

Hope it helps.

umer.nalla

Hi @karun.matharu

Our realtime APIs are content-agnostic - they just deliver the data as provided by the server you are connecting to.
If you think about it, the API is running locally on your PC. So, even if an API was able to add some UID to each update, that UID would be specific to that instance of the application - and the same app running on another PC could inject different IDs.

karun.matharu

HI Umer, thank you for your response, apologies for the ambiguity in my question. I wouldn't expect the client API to add a message identifier as this would defeat the purpose as you say. I was referring to parameters which come through the feed (and methods for accessing those parameters) . In order to have resiliency as described I would need to be able to combine both feeds in real time. In essence if the sequence number was a sequence I would be able to do this fine but that isn't the case.

Has this type of resiliency ever been raised by clients before? How would you recommend achieving this? (warm standby would't be suitable for my use case unfortunately)