question

Upvotes
Accepted
1 0 0 0

ETA Hot-Standby resiliency

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

elektronrefinitiv-realtimeelektron-sdkrrteta-apielektron-transport-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

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.


Hello @karun.matharu

Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?

If yes, please click the 'Accept' text next to the reply. This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.

Thanks,

AHS

@karun.matharu

Hi,

Thank you for your participation in the forum.

Are any of the replies below satisfactory in resolving your query?

If yes please click the 'Accept' text next to the most appropriate reply. This will guide all community members who have a similar question.

Otherwise please post again offering further insight into your question.

Thanks,

AHS

Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.

Thanks,

AHS

Upvotes
Accepted
22.1k 59 14 21

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
1 0 0 0

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)

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.