Can anyone explain/point to the detailed documentation for obeyOpenWindow attribute in ConsumerWa...

RG1

...tchListOptions in ETA reactort API

What is exactly

chnlInfo.consumerRole.watchlistOptions().obeyOpenWindow(true); 

in WatchlistConsumer java example. Java doc only mentions "Controls whether item requests obey the OpenWindow provided by a service. " , and dev guide says "Sets whether the Reactor obeys the OpenWindow of services advertised in a provider’s Source Directory response. " But do not see anything relevant to the open window in service directory. Thank you

zoya faberov

Hello @RG1 ,

Please refer to Transport API C RDM Usage Guide,

OpenWindow:

Maximum number of outstanding requests (i.e., requests for items not yet open) that the service will allow at any given time. If OpenWindow is 0, the behavior is the same as setting AcceptingRequests to 0 and no open item request is accepted. The provider should not assume that the OpenWindow becomes effective immediately

---

The consumer can follow max OpenWindow as defined, or it can submit requests regardless. If the requests are submitted too fast, they may pile up, filling up and eventually overfilling the allocated buffers, never a good idea, and possibly resulting in a disconnect.

Hope that this information helps

RG1

Thank you, Zoya. Large OpenWindow for a service must be pretty bad as well ( I see 4294967295 value in service deirectory) . What's the optimal value for OpenWindow?

zoya faberov

Hello @RG1 ,

I am expressing my view, not the official recommendation from the product, especially that this will differ per your infra connectivity.

There are two ways of handling this aspect if you wish to maintain heavy subscription.

1. Partition the heavy request requirement into reasonable batches and request in batches, while introducing a minimal wait between batches. This is simpler and most commonly used.

2. Continuously examine open requests before issuing the next batch, configure open request window target and restrict submission, until you can submit under target. This is more complex.

a. If your infra is RTTO, you should never request, in total, above your permissioned watch list size. If you are submitting snapshots and subscriptions, as snapshots get processed, and subscriptions- unsubscribed, the total open should never exceed your id's watchlist size permissioned.

b. If you are RTDS, and if you wish to go the second route, you may opt to consult with your market data team, they will know what are the buffers/thresholds/other configs on your infra and what would be a reasonable number of the open requests.

In both cases, I prefer the conservative approach, the less outstanding requests are there- the less buffers are engaged, and the less latency is incurred.

Hope this information helps