we are using java ema and have queries on reissue, emaconfig.xml and fid level subscription

gowrisankar.dasarathan
gowrisankar.dasarathan Newcomer
edited February 17 in EMA

  1. Verify whether we can reliably use a reissue request to safely cause a refresh;

(note: The issues I experienced with this (reloading all instruments) was an unrelated GC issue.  Further tests have shown that requesting a reissue appears to work fine for a single EPIC – I just need confirmation that this is the right way to proceed)

  1. Find out how to configure EmaConfig.xml to randomly assign channels at startup, in order to avoid straining the first channel.

(assuming it’s possible; the alternative would be to revert to programmatic configuration);

  1. Is there a case for using views to reduce the number of fields we’re getting?  Does this carry a performance advantage?  Is it something that would need to be setup serverside, in which case would it entail additional work on ADS?
Tagged:

Answers

  • wasin.w
    wasin.w admin

    Hello @gowrisankar.dasarathan

    Question 1: Verify whether we can reliably use a reissue request to safely cause a refresh. Further tests have shown that requesting a reissue appears to work fine for a single EPIC

    Answer: I do not understand the question. However, the EMA API does not support batch re-issue and batch close items as the shown on the API Concepts Guide document.

    apis_features.png

    The API supports a single RIC reissue.

    Question 2: Find out how to configure EmaConfig.xml to randomly assign channels at startup, in order to avoid straining the first channel.

    Answer: I am assuming that you are using the ChannelSet configuration. The ChannelSet connection is based on the order of channels in the values setting. The EmaConfig.xml file does not support the random order setting, so you need to use the programmatic configuration and random set the order of ChannelSet values instead.

    Question 3: Is there a case for using views to reduce the number of fields we’re getting?  Does this carry a performance advantage?  Is it something that would need to be setup serverside, in which case would it entail additional work on ADS?

    Answer: The API requests all field data for an application by default. Using the View feature lets an application subscribes to only interested fields which can save a network bandwidth between the API and Server because it does not load the unwanted data fields.

    About the ADS setting for the View, the ADS server configurations should enable View by default via enableViews configuration. Unless your Market Data team has disabled it manually.

    ! *ads*enableViews : True
!#help
!    enableViews: { True, False }
!
!    This parameter enables the view requests feature which allows applications to request specific
!    fields for a Level 1 record. If set to false, the view requests will be responded with full
!    images, the same as normal requests.
!
!    Default value: True

Categories