Hello @Raj.Huang,

What is the version of EMA Java you are using? Does the ADS server or your TREP server is running when a network problem occurs?

I cannot replicate the issue in my environment with EMA Java 1.1.1 by restart the ADS server or disconnect-reconnect network. The API can recover connection and subscription instantly. Please see my results in attachment.

2017-11-06 11:34:06.846 WARNING com.thomsonreuters.ema.access.ChannelCallbackClient reactorChannelEventCallback 
loggerMsg
    ClientName: ChannelCallbackClient
    Severity: Warning
    Text:    Received ChannelDownReconnecting event on channel Channel
    RsslReactor Channel is null
    Error Id 0
    Internal sysError 0
    Error Location Reactor.processWorkerEvent
    Error text Error initializing channel: errorId=-1 text=No route to host: no further information
loggerMsgEnd

2017-11-06 11:34:11.854 WARNING com.thomsonreuters.ema.access.ChannelCallbackClient reactorChannelEventCallback 
loggerMsg
    ClientName: ChannelCallbackClient
    Severity: Warning
    Text:    Received ChannelDownReconnecting event on channel Channel
    RsslReactor Channel is null
    Error Id 0
    Internal sysError 0
    Error Location Reactor.processWorkerEvent
    Error text Error initializing channel: errorId=-1 text=No route to host: no further information
loggerMsgEnd

2017-11-06 11:34:16.862 INFO    com.thomsonreuters.ema.access.ChannelCallbackClient reactorChannelEventCallback 
loggerMsg
    ClientName: ChannelCallbackClient
    Severity: Info
    Text:    Received ChannelUp event on channel Channel
    Instance Name EmaConsumer_1
    Component Version ads3.1.1.L1.linux.tis.rrg 64-bit
loggerMsgEnd

2017-11-06 11:34:16.865 FINEST  com.thomsonreuters.ema.access.LoginCallbackClient rdmLoginMsgCallback 
loggerMsg
    ClientName: LoginCallbackClient
    Severity: Trace
    Text:    RDMLogin stream was open with refresh message
    LoginRefresh: 
    streamId: 1
    name: user
    nameType: 1
    State: Open/Ok/None - text: "Login accepted by host apis11."
    isSolicited: true
    applicationId: 256
    applicationName: ADS
    position: 10.42.68.162/U8004042-TPL-A
    providePermissionProfile: 0
    providePermissionExpressions: 1
    singleOpen: 1
    allowSuspectData: 1
    supportBatchRequests: 1
    supportBatchReissues: 1
    supportBatchCloses: 1
    supportOMMPost: 1
    supportOptimizedPauseResume: 1
    supportStandby: 1
    supportViewRequests: 1
    supportEnhancedSymbolList: 1

    
loggerMsgEnd

Hi @Raj.Huang

Basically, the EMA connection/reconnect logic and time are based on the following EMA configurations

• DictionaryRequestTimeOut
• DirectoryRequestTimeOut
• LoginRequestTimeOut
• ReconnectAttemptLimit
• ReconnectMaxDelay
• ReconnectMinDelay

I have checked the given log file. It contains a lot of "login failed (timed out after waiting 45000 milliseconds) for 122.144.182.147:14002)", "Error - exceeded initialization timeout (5 s)", "dictionary retrieval failed (timed out after waiting 45000 milliseconds) for 122.144.182.147:14002)" messages. They mean the API cannot establish connection with the TREP server during that time (cannot login and request dictionary from TREP). Does the ADS (or EZD) was started during that time?

Please be inform that once the API can reconnect to TREP, it automatic resubscribes all items for the application and the application will receive the latest real time updated data.

If you need a "history" data during a connection lost period, you may need to use a Tick History API like Thomson Reuters Tick History (TRTH) - REST API to consume that Tick History data instead. Please note that provide Tick History data for each day is available when market close time + 120 minutes only.

Hi @Wasin Waeosri,

Thanks for your reply.

1st, I didn't set the EMA configurations, so it's all defalut value. Then, I notice that the reconnection delay should be from 1000ms to 5000ms, right? However, according to the log I attached, taking "Consumer_1_1" as an example, the interval reached 22 minutes which causes the problem mentioned in the 2nd point.

2nd, as the interval is too long, it may cause data loss. For example, my network is broken at 15:00 and it recovers at 16:10, and the application reconnects at 15:00, 15:20, 15:40, 16:00, 16:20, so my application reconnects at 16:20 successfully. However, the network recovers at 16:10, it should connect at 16:10 instead of 16:20, so I lost 10 minutes of data because of the long interval.

In a word, my application doesn't reconnect every (1000ms to 5000ms) according to the log, so can you help me check this?