TunnelStream.readMsg() Exception

I have recently upgraded to EMA 3.6.8.0 and am now getting the following error:

INFO: StatusMsg
    streamId="6"
    domain="System Domain"
    privateStream
    state="Closed, Recoverable / Suspect / None / 'TunnelStream.readMsg() Exception: 38'"
    name="TUNNEL1"
    serviceId="10"
    serviceName="DDS_TRCE"
StatusMsg

What is confusing me is the fact that this code has been working correctly on a previous version and works in UAT against our test RICS, but when we move to production we get this error. The exception number is always the number of RICS that we are contributing, except somethings we get a '/ by zero' exception instead.

I have changed and mixed about which RIC codes we send (all are valid) but there doesn't seem to be any pattern to it except when the number exceeds a certain threashold

There is also no attempt to reconnect after this type of error

Find more posts tagged with

ema-api

#technology

Accepted answers

JasonS

I have found the problem! The onAck method was throwing a runtime exception that was obviously being swallowed. The nature of the error was a bit intermitant, so was difficult to see.

Is there any reason that an error within the onAck isn't reported?

Thank you for your help in this matter!

All comments

Jirapongse

@JasonS

Thanks for reaching out to us.

According to the status message, the stream state of the tunnel stream is Closed - Recoverable.

Typically, the API will not recover the tunnel stream. The application needs to do it.

We have updated the tutorial code that shows how to recover the tunnel stream but it may not cover all scenarios. Moreover, the development team recommends using the RSSL_SOCKET encrypted protocol type, instead of RSSL_HTTP.

<EncryptedProtocolType value="EncryptedProtocolType::RSSL_SOCKET"/>

To investigate this issue, we need to check why the tunnel stream has been closed.

You can enable tracing in the API to verify the messages sent and received by the API. The trace can be enabled by using the following configuration in the Consumer setting.

JasonS

So I have re-coded based on the new tutorial example and tested it and I get the same result (we are publishing 150 currency pairs every second, once the number gets above 30 it keeps causing the error).

When I turn on the XmlTrace I can see the messages being sent and the ack's starting to coming back, but then there is an outgoing close message (shown below)

<!-- Outgoing Reactor message -->
<!-- java.nio.channels.SocketChannel[connected local=/192.168.1.222:57913 remote=contrib1-emea1.platform.refinitiv.com/54.77.38.155:443] -->
<!-- Wed Jan 25 17:26:21 GMT 2023 -->

<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<CLOSE domainType="SYSTEM" streamId="4" containerType="NO_DATA" flags="0x00" dataSize="0">
    <dataBody>
    </dataBody>
</CLOSE>

This is followed by the error message

Jan 25, 2023 5:26:21 PM com.refinitiv.ema.access.TunnelItem submitSubItemMsg
SEVERE: loggerMsg
    ClientName: TunnelItem
    Severity: Error
    Text:    Internal Error. Failed to submit message in TunnelItem.submitSubItemMsg
loggerMsgEnd

I am not sure what is causing this message to be sent?

Jirapongse

@JasonS

According to the error, the tunnel stream may be closed because it failed to submit a message to the tunnel. However, the error didn't show any reason.

However, it may relate to the size of the buffers. You can try to increase the number of buffers.

First, you need to call the TunnelStreamRequest::guaranteedOutputBuffers method to increase the number of buffers used in the TunnelStream.

            TunnelStreamRequest tsr = EmaFactory.createTunnelStreamRequest()
                .classOfService(cos)
                .domainType(EmaRdm.MMT_SYSTEM)
                .name("TUNNEL1")
                .serviceName("DDS_TRCE");
            
            tsr.guaranteedOutputBuffers(5000);

Then, you need to set the GuaranteedOutputBuffers configuration of the Channel in EMA configurations. For example:

        <Channel>
            <Name value="Channel_1"/>
            <ChannelType value="ChannelType::RSSL_ENCRYPTED"/>
             ...
            <GuaranteedOutputBuffers value="5000"/>
             ...

If this doesn't solve the problem, please share the full trace and log file.

I am still unable to replicate this issue.

I have modified the sample code to contribute multiple items and the code works fine. Please see the attached file (Contributor.java.txt).

You can share the runnable code that can be used to replicate the problem so we can verify and run the code

JasonS

I have found the problem! The onAck method was throwing a runtime exception that was obviously being swallowed. The nature of the error was a bit intermitant, so was difficult to see.

Is there any reason that an error within the onAck isn't reported?

Thank you for your help in this matter!

Jirapongse

@JasonS

I checked the code can found that the API internally handles exceptions.

EXPLORE OUR SITES