RFA C++ consumer application dis not reconenct to ADS
A RFA consumer application receives an OMM Connection event with the following details:
ConnectionName:'Connection_RSSL' Host:206.100.1.240, Port:14002, ComponentVersion:'ads3.2.2.L1.linux.tis.rrg 64-bit', State:Up(1), StatusCode:None(1), StatusText:'Connection up'
Shortly after a login response with the following details is received:
respType:Status, streamState:'Closed', dataState:'Suspect', statusCode:'Timeout', statusText:'A21: Access Denied. Timed out waiting for response from DACS server. Try request again.'
Why does the ADS send a closed in this case while its waiting for DACS server?
Should it not not send a "closed recover" in this case which will mean that RFA will retry login.
Whether further login attempts succeed or not will depend on the nature of the ADS to DACS timeout issue. If it's of a transient nature then the later attempts should succeed. However, if it is something more serious, then continuously retrying would not be the best approach.
Therefore, what you could do is try a limited number of times with a short delay between each attempt.
You should also look sending an alert to initiate some human involvement to investigate and rectify the problem. This could be immediately after the first attempt fails - as there really should NOT be a timeout issue between your ADS and DACS - or you could delay till your subsequent attempts also fail.
In my experience of helping RFA developers I have rarely seen a timeout issue between the ADS and DACS - so it really should be investigated and resolved.
The 'Closed Recover' scenario applies to data items - where you have requested a valid instrument, which is unavailable (for whatever reason) at this point in time - but should be available if you try again later.
In terms of the DACS timeout, you should discuss with your Market Data team so they can investigate the cause of the timeout. If they require assistance, they should raise a ticket with TREP support .
If the problem was with connectivity to the ADS itself, then the API should try to reconnect where possible - however, here the problem appears to be at the ADS to DACS level.
In this case should the application keep sending a login request until sucessful or is there no chance of a login suceeding?
What is the recommended course of action?
I am not a TREP expert, but I had a quick read of the ADS install guide and noted the following entry:
Setting the following parameter to True, causes the ADS to send a CLOSED_RECOVER status instead. This allows RFA to recover data on behalf of the application:
A *ads*dacs*sendCloseRecovOnTimeout : False
So, please check with your Market Data team to see if the above is set to False, whether they can change it to true.
If the paramter *ads*dacs*sendCloseRecovOnTimeout is set to TRUE will the CLOSED_RECOVER be received by the application or will it be silently handled by RFA.