question

Upvotes
Accepted
LtDoolittle6 avatar image
301 ●14 ●33 ●39

ADS not updating it's cached image for a replaced Map Entry

Hi,

Both the RFAJ v7.5 and UPAJ v8.0 Developer Guides document that an ADD Action on an OMMMapEntry (OMMMapEntry.Action.ADD in RFA terms) is used to add or replace an entry.

We are using this Action to affect a Map Entry replace however, it seems as though the ADS (v2.5.0.L1 in our case) is instead ignoring the update and not modifying the Item’s entry within its cache. As a result, any concurrent subscriptions for the same Item will result in an outdated image being returned by the ADS from its cache.

Is this a known issue, or are we doing something wrong on our side?

Any insight into whether this is an issue with the ADS, our implementation / understanding of the correct OMM usage would be greatly appreciated.

elektronrefinitiv-realtimetrepADScachingmap-entry
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.

1 Answer

· Write an Answer
Upvotes
Accepted
Bondy_Bo avatar image
588 ●14 ●21 ●19

Adds do not replace in the cache for TREP. An add for an entry already present will be ignored. That entry instead should receive an update or a delete followed by an add to be processed by the cache.

I’m not sure the RFA and UPA docs are completely accurate in their descriptions although this could be debatable between robustness and function.

In other words, an order book provider should never add a row that already exists. This would be an error in processing and enforced at the downstream caches. However, if the delete is lost, a subsequent add for the same row will get lost.

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.