InitailizationTimeout is 0 sec

Hi,

I programmatically set consumer, channel and dict configs (EMA, C++, Real-Time-SDK-2.0.1.G1 ). I do not explicitly set initilizationTimeout config value. But for some reason it is set to 0 by default. Any reason for this ? I expect it is to be set to 10 sec since channel type is ENCRYPTED.


 loggerMsg
TimeStamp: 01:46:12.551
ClientName: ChannelCallbackClient
Severity: Verbose
Text: Attempt to connect using
1] RSSL_CONN_TYPE_ENCRYPTED
Channel name Channel_0
Instance Name Consumer_0_10
RsslReactor 0x0x7f1fc2cfd550
InterfaceName
hostName
port
CompressionType None
tcpNodelay false
ObjectName
ProxyHost
ProxyPort
SecurityProtocol 4
EnableSessionManagement 1
Location eu-west-1
reconnectAttemptLimit 10
reconnectMinDelay 1000 msec
reconnectMaxDelay 5000 msec
connectionPingTimeout 60000 msec
initializationTimeout 0 sec
Tagged:

Best Answer

  • Jirapongse
    Jirapongse ✭✭✭✭✭
    Answer ✓

    @thilinaillangasinghe

    I found that this issue has been fixed in RTSDK 2.0.6.L1.

    EMA C++ 3.6.6.L1 Issues Resolved

    • [RTSDK-1486] - Fix to EMA examples to account for MapEntry key which can be Buffer, Ascii or Rmtes
    • [RTSDK-6099] - Port is not released after destroying OMMProvider [GitHub #192]
    • [RTSDK-6125] - Ensure that LibcurlName can be specified via programmatic config (removed from file config)
    • [RTSDK-6150] - EMA_Config Guide shows duplicate definitions: NumberOfLogFiles, Filename, etc
    • [RTSDK-6168] - InitializationTimeout does not take effect via programmatic config [GitHub #196]
    • [RTSDK-6302] - EMAC++'s default Login request does not have the correct position on Windows
    • [RTSDK-6290] - Cons470 Segmentation fault when connect to server doesn't support warmstandby and Ctrl+C

Answers

  • Jirapongse
    Jirapongse ✭✭✭✭✭

    @thilinaillangasinghe

    I tested with RTSDK 2.0.5.L1 and found that if I specify the host and port in the encrypted channel, the value of initializationTimeout is 10 seconds.

    loggerMsg
        TimeStamp: 14:37:14.284
        ClientName: ChannelCallbackClient
        Severity: Verbose
        Text:    Attempt to connect using 
        1] RSSL_CONN_TYPE_ENCRYPTED
        Channel name Channel_1
        Instance Name Consumer_1_1
        RsslReactor 0x0000015EFD510D30
        InterfaceName 
        hostName us-east-1-aws-3-med.optimized-pricing-api.refinitiv.net
    port 14002

        CompressionType None
        tcpNodelay true
        ObjectName 
        ProxyHost 
        ProxyPort 
        SecurityProtocol 4
        EnableSessionManagement 1
        Location us-east-1
        ServiceDiscoveryRetryCount 3
        reconnectAttemptLimit -1
        reconnectMinDelay 1000 msec
        reconnectMaxDelay 5000 msec
        connectionPingTimeout 60000 msec
        initializationTimeout 10 sec
        
    loggerMsgEnd

    However, if I specify the Location in the encrypted channel, the value of initializationTimeout is 16711950 seconds.

    loggerMsg
        TimeStamp: 14:39:57.108
        ClientName: ChannelCallbackClient
        Severity: Verbose
        Text:    Attempt to connect using 
        1] RSSL_CONN_TYPE_ENCRYPTED
        Channel name Channel_1
        Instance Name Consumer_1_1
        RsslReactor 0x000002618AAC0D10
        InterfaceName 
        hostName 
        port 
        CompressionType None
        tcpNodelay true
        ObjectName 
        ProxyHost 
        ProxyPort 
        SecurityProtocol 4
        EnableSessionManagement 1
        Location us-east-1
        ServiceDiscoveryRetryCount 3
        reconnectAttemptLimit -1
        reconnectMinDelay 1000 msec
        reconnectMaxDelay 5000 msec
        connectionPingTimeout 60000 msec
        initializationTimeout 16711950 sec
        
    loggerMsgEnd

    This could be a bug in the API. If you are an RDC named contact, you can submit this issue to the API support team directly via Contact Premium Support on the Refinitiv Developer Portal website.

    Otherwise, you can raise this issue via GitHub.

  • Thanks for the reply. Experienced the same from my side only when configs are set programatically. Whenever channel info are described via EmaConfig file, did not experience this issue.