ETA application - RTO disconnect

I have a C ETA consumer application which allows connections to be made to RTO. At the customer site, they lost their connection to RTO but it didn't recover as expected and had to be restarted. After restart the application worked as expected.

The question I have is - if an RTO endpoint disconnects, can we just reconnect to it ( i.e. call rsslReactorConnect() ) or do we need to reissue the call to rsslReactorQueryServiceDiscovery() as well ?

Find more posts tagged with

connection

reactor

disconnection

rrto

eta-api

Accepted answers

Jirapongse

The case has been closed with the following resolution.

According to the error message, the credential parameter is wrong when making a reconnection. We recommend always setting credential parameters before calling connect function.

All comments

Gurpreet

Hi @andy.sciascia,

Is you application based on value add reactor? See the VAConsumer example provided with ETA, which shows that VA is able to automatically handle the reconnects.

Jirapongse

@andy.sciascia

As mentioned by my colleague, typically, the ETA Value Added Reactor can handle reconnections on behalf of an application but the application needs to resubscribe to all subscribed items.

However, you can use the ETA Value Added Reactor with Watchlist enabled that can handle both reconnections and resubscriptions on behalf of the application.

In this case, you need to verify why the connection has been disconnected. You can contact the RTO support team directly via MyRefinitiv to check the server log.

As I know, there is one scenario that ETA Value Added Reactor will not reconnect to the server. If the server sent a login close message to the application, the ETA Value Added Reactor will not reconnect to the server. Therefore, the application needs to implement a logic to reconnect and resubscribe when receiving the login close message from the server.

andy.sciascia

We do re-subscribe if we reconnect - that's not the issue.

Also, our application works with non-RTO as well and reconnection is handled by the library fine in that case. However in this particular instance with RTO it wasn't.

The initial issue was with DACS and that is why I thought that maybe if we reissued the Discovery command before the reconnect command that it might address the issue.

2022/08/06-05:05:10.266309 +0000: (upasrc-load-3): INFO: ETA Reactor: Login status code <State: Closed/Suspect/Not entitled - text: "Force Logout from DACS."> 
2022/08/06-05:05:10.266327 +0000: (upasrc-load-3): INFO: ETA: Closing channel (0x7f2aac1836c0)
2022/08/06-05:05:10.271625 +0000: (upasrc-load-3): INFO: ETA: Name: RWFFld,Domain: RSSL_DMT_DICTIONARY, stream: [00003] Msg Class: RDM_DC_MT_STATUS, <State: Closed/Suspect/None - text: "Login stream was closed.">
2022/08/06-05:05:10.271657 +0000: (upasrc-load-3): INFO: ETA: Name: RWFEnum,Domain: RSSL_DMT_DICTIONARY, stream: [00004] Msg Class: RDM_DC_MT_STATUS, <State: Closed/Suspect/None - text: "Login stream was closed.">

We're also getting logs from the library suggesting that the credentials have been "lost"

2022/08/06-05:05:20.269067 +0000: (upasrc-load-3): INFO: ETA: Connecting to eu-west-1-aws-3-med.optimized-pricing-api.refinitiv.net:14002
2022/08/06-05:05:20.397005 +0000: (upasrc-load-3): ERROR: ETA: Connection error, will try again shortly: (Failed to request authentication token information with HTTP error 400. Text: {"error":"access_denied"  ,"error_description":"Invalid username or password." } )
...
2022/08/06-05:05:50.268628 +0000: (upasrc-load-3): INFO: ETA: Connecting to eu-west-1-aws-3-med.optimized-pricing-api.refinitiv.net:14002
2022/08/06-05:05:50.306552 +0000: (upasrc-load-3): ERROR: ETA: Connection error, will try again shortly: (Failed to request authentication token information with HTTP error 400. Text: {"error":"invalid_request"  ,"error_description":"Request is missing username parameter." } )

But the token information is set up in the connection structure and was working ok previously.

Jirapongse

@andy.sciascia

The server sent the login closed status message to the application so API will not recover the connection.

2022/08/06-05:05:10.266309 +0000: (upasrc-load-3): INFO: ETA Reactor: Login status code <State: Closed/Suspect/Not entitled - text: "Force Logout from DACS.">

For the error "Failed to request authentication token information", you can enable the REST log to verify the request message.

reactorOpts.restEnableLog = restEnableLog;
reactorOpts.restLogOutputStream = restLogFileName;

andy.sciascia

Re the connection recovery. In this case you say the API won't recover the connection - I assume even when DACS recovers.

However - when an issue like this happens - the application closes the connected channels and makes periodic attempts to reconnect by calling rsslReactorConnect().

But these reconnect attempts that failed ( even when DACS recovered ).

Re-starting the application fixed the issue. The main difference between the reconnect attempts and a restart is that

- in a reconnect attempt we just keep reissuing the rsslReactorConnect() call

- when we restart we issue the rsslReactorQueryServiceDiscovery() and then the rsslReactorConnect() call.

If I updated the application reconnection code to issue the rsslReactorQueryServiceDiscovery() and then the rsslReactorConnect() call would you expect that we should reconnect when the DACS issue is resolved ?

Jirapongse

@andy.sciascia

Yes, you are correct. To reconnect, there is no need to call rsslReactorQueryServiceDiscovery() because the application already knows the endpoint that it will connect to.

You need to specify username, password, and clientID in the RsslReactorOAuthCredential.

typedef struct
{
    RsslReactorChannelRoleBase        base;                  
    RsslRDMLoginRequest                *pLoginRequest;           
    RsslBuffer                        clientId;             
    RsslReactorOAuthCredential        *pOAuthCredential;      
    RsslRDMLoginMsgCallback            *loginMsgCallback;      
    RsslRDMDirectoryRequest            *pDirectoryRequest;     
    RsslRDMDirectoryMsgCallback        *directoryMsgCallback; 
    RsslDownloadDictionaryMode        dictionaryDownloadMode;  
    RsslRDMDictionaryMsgCallback    *dictionaryMsgCallback;  
    RsslConsumerWatchlistOptions     watchlistOptions;      
} RsslReactorOMMConsumerRole;

From the error, it looks like the credential is incorrect or missing.

2022/08/06-05:05:20.269067 +0000: (upasrc-load-3): INFO: ETA: Connecting to eu-west-1-aws-3-med.optimized-pricing-api.refinitiv.net:14002
2022/08/06-05:05:20.397005 +0000: (upasrc-load-3): ERROR: ETA: Connection error, will try again shortly: (Failed to request authentication token information with HTTP error 400. Text: {"error":"access_denied"  ,"error_description":"Invalid username or password." } )
...
2022/08/06-05:05:50.268628 +0000: (upasrc-load-3): INFO: ETA: Connecting to eu-west-1-aws-3-med.optimized-pricing-api.refinitiv.net:14002
2022/08/06-05:05:50.306552 +0000: (upasrc-load-3): ERROR: ETA: Connection error, will try again shortly: (Failed to request authentication token information with HTTP error 400. Text: {"error":"invalid_request"  ,"error_description":"Request is missing username parameter." } )

You may need to enable the REST log to verify the request message.

reactorOpts.restEnableLog = restEnableLog;
reactorOpts.restLogOutputStream = restLogFileName;

andy.sciascia

The problem is that the credential information has already been set up in static memory that we never change. Also there was an original successful connection before this issue happened so the credentials must have been correct initially.

We set up a consumerRole.pOAuthCredential for every channel and we never change that. All we ever do with the consumerRole information is pass it to the initial rsslReactorConnect() call and to the same API whenever we try to reconnect after any event that causes a close of the connection.

Is there something in the library that can change the initial credentials we provide ?

Jirapongse

@andy.sciascia

I found that there are RDC (Refinitiv Developers Connect) contacts in your organization. Therefore, please contact the API support team directly via Contact Premium Support.

Then, the API support team will verify if this is a problem in the application or API.

Jirapongse

The case has been closed with the following resolution.

According to the error message, the credential parameter is wrong when making a reconnection. We recommend always setting credential parameters before calling connect function.

EXPLORE OUR SITES