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