I'm using RFAJ to subscribe to data. If the process starts early (e.g. Sunday) and requests some symbols via IDN we get back unavailable responses
Moving to use 14002 in fx_connections_reuters.ql I get a lot more including say CNH10M=UBSZ
Service: IDN_SELECTFEED Item: CNH10M=UBSZ MESSAGE
Msg Type: MsgType.STATUS_RESP
Msg Model Type: MARKET_PRICE
Hint Flags: HAS_ATTRIB_INFO | HAS_STATE
State: CLOSED, SUSPECT, NOT_FOUND, "The record could not be found"
NameType: 1 (RIC)
My reading of the docs suggest CLOSED means that it is closed but can reopen. But when the feed becomes available I don't see any data. If I restart my application (and remake the subscription request) then I get data.
Should I be retrying sending subscriptions periodically or is there a way to get RFA to handle this?
When a stream is closed, it will not be re-opened on your behalf.
If you are certain the RIC is a valid one and should be available then you will need to re-request the item again.
One thing I am puzzled about is when you say 'when the feed becomes available' - not sure what you mean by that? The status message you provided above indicates the Feed and the IDN_SELECTFEED service are both up and running - just that the particular RIC is not a valid one (at this point in time?) - otherwise you would not be getting the above status message.
For re-requesting 'not found' instruments we normally advise a controlled retry logic, for example: If an item is not found but certain it is a valid item then the RIC should be added to a recovery queue. After a short wait period, you could try again, and if still not found wait longer before attempting the same RIC again. After several failed attempts (each one after an increasingly longer wait time) then it would be sensible to abandon any further attempts on that RIC. The timings and number of retry attempts is something you need to determine to ensure you don't overwhelm the servers with too many repeat requests for items that are not (yet) available or may well be genuinely invalid RICs.
Hi, that is really useful thanks!
The case is indeed one for which the symbol happens not to be available and then becomes available, but the IDN_SELECTFEED is available.
So I should check for the "Not Found" status and in this case do exponential backoff and resubscribe?