state="Open / Suspect / None / 'channel down.' when send Batch request

cho.seungjin

Hello.

I'm trying to register 4,000 items with batch request.

But It failed with below message, event I deleted all consuming logics at out Application, it still happen.

I'm guessing there might be problem with EmaConfig.xml,, so I attached my config here.

            <Consumer>
                <Name value="LocalConsumer"/>
                <!-- channel is optional: defaulted to "RSSL_SOCKET + localhost + 14002" -->
                <Channel value="ChannelReplay1"/>
                <!-- logger is optional: defaulted to "Stdout + Success" -->
                <Logger value="LoggerFile"/>
                <ItemCountHint value="20000"/>
                <!--<ServiceCountHint value="655"/>-->
                <ObeyOpenWindow value="0"/>
                <PostAckTimeout value="10000"/>
                <RequestTimeout value="10000"/>
                <MaxOutstandingPosts value="90000"/>
                <DispatchTimeoutApiThread value="90"/>
                <MaxDispatchCountApiThread value="400"/>
                <MaxDispatchCountUserThread value="5"/>
                <!--ReactorEventFdPort value="75000" -->
                <PipePort value="7001"/>
                <ReconnectAttemptLimit value="10"/>
                <ReconnectMinDelay value="10000" />
                <ReconnectMaxDelay value="15000" />
                <XmlTraceFileName value="EmaMyTrace"/>
                <XmlTraceMaxFileSize value="66666666" />
                <XmlTraceToFile value="0" />
                <XmlTraceToStdout value="0" />
                <XmlTraceToMultipleFiles value="1" />
                <XmlTraceWrite value="1"/>
                <XmlTraceRead value="1"/>
                <XmlTracePing value="1"/>
                <XmlTraceHex value="1"/>
                <MsgKeyInUpdates value="1"/>
                <!-- dictionary is optional: defaulted to "ChannelDictionary" -->
                <Dictionary value="DictionaryFile"/>
            </Consumer>

<Channel>
    <Name value="ChannelReplay1"/>
    <!-- channelType possible values are: -->
    <!-- ChannelType::RSSL_SOCKET    - TCP IP connection type (supported in EAP) -->
    <!-- ChannelType::RSSL_HTTP      - Http tunnel connection type (not yet supported in EAP) -->
    <!-- ChannelType::RSSL_ENCRYPTED - Https tunnel connection type (not yet supported in EAP) -->
    <!-- ChannelType::RSSL_RELIABLE_MCAST - MCAST connection type (not yet supported in EAP) -->
    <ChannelType value="ChannelType::RSSL_SOCKET"/>
    <!-- compressionType is optional: defaulted to None -->
    <!-- possible values: None, ZLib, LZ4 -->
    <CompressionType value="CompressionType::None"/>
    <GuaranteedOutputBuffers value="100000"/>
    <NumInputBuffers value = "7000" />
    <SysRecvBufSize value= "569823" />
    <SysSendBufSize value= "569823" />
    <HighWaterMark value= "3000" />
    <CompressionThreshold value= "2048" />

    <!-- connectionPingTimeout is optional: defaulted to 30000 -->
    <ConnectionPingTimeout value="30000"/>

    <!-- tcpNodelay is optional: defaulted to 1 -->
    <!-- possible values: 1 (tcp_nodelay option set on the channel), 0 (tcp_nodelay not set on the channel) -->
    <TcpNodelay value="1"/>
    <Host value="10.121.56.11"/>
    <Port value="14002"/>
    <DirectWrite value= "1" />
</Channel>

umer.nalla

Hi @cho.seungjin

Thanks for providing the additional log output.

However, there is no problem indicated in the above extract.

1. The high water mark message just confirms that the HighWaterMark value that you specified in your config has been successfully set.
2. The following 3 Batch Stream Closed status messages are actually normal and expected. When you make a successful batch request, each item in your batch is allocated an individual stream and the originating Batch stream is closed off as it is no longer required - note the incrementing StreamIDs of each subsequent batch request...

The service name hEDD indicates a direct feed - so there could be some configured limitation / restriction on the Direct feed device. OR it could be that due to the high volatility nature of the instrument, your application may be struggling to cope with the update rate for your 12,000 items - causing the disconnect from the server. If this is the case, you may need to split your processing across multiple OmmConsumer instances - using the Horizontal Scaling technique as demonstrated in example 410_MarketPrice_HorizontalScaling. You can off course combine Batch Processing with Horizontal Scaling.

You can also open a support ticket in order to investigate your issue in more detail - which is outside the scope of this forum.