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

LtDoolittle6

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.

Bondy_Bo

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.