EMA Post Contribution doesn't always return NACK/ACK Message

Hi there, I have had some trouble debugging my EMA application in the last few days, I am using EMA to contribute data to via TREP to Refinitiv. I had followed all of the tutorials correctly and posted sample contributions which worked fine. And then moved onto creating my own test RICs which I made code to publish data to. All of this worked fine.

As I progressed to writing my final implementation, my code was adding an additional field into the Page header which I was posting. I would expect this to return an error NACK such as the following

AckMsgEnd
>FF
May 13 17:01:12.692 +0100 - Thread [pool-5-thread-1/18]: INFO: ACK/NACK <AckMsg
    streamId="1"
    domain="MarketPrice Domain"
    ackId="0"
    nackCode="DeniedBySource"
    text="Encoded data length exceeds RWF length Fid Id [340] [Failed to apply update. Cache build failed]"
    name="/RIC"
    nameType="1"
    serviceId="259"
AckMsgEnd

However we were simply not getting back any ACK or NACK at all on these unsuccessful contributions which led us to believe that the application was working correctly.

May 17 17:33:57.378 +0100 - Thread [pool-3-thread-1/23]: INFO: Received update for /TEST/TEST1 of type PageMessage.
May 17 17:33:57.379 +0100 - Thread [pool-3-thread-1/23]: INFO: Publishing page of Image type.

May 17 17:33:57.389 +0100 - Thread [pool-3-thread-1/23]: INFO: Posting update for SERVICE TEST1 type INITIAL
May 17 17:33:57.392 +0100 - Thread [pool-3-thread-1/23]: INFO: Received update for /TEST/TEST1 of type PageMessage.
May 17 17:33:57.392 +0100 - Thread [pool-3-thread-1/23]: INFO: Publishing page of Image type.

May 17 17:33:57.403 +0100 - Thread [pool-3-thread-1/23]: INFO: Posting update for SERVICE /TEST1 type INITIAL
May 17 17:33:57.405 +0100 - Thread [pool-3-thread-1/23]: INFO: Received update for /TEST/TEST1 of type PageMessage.
May 17 17:33:57.406 +0100 - Thread [pool-3-thread-1/23]: INFO: Publishing page of Image type.

The above snippet of code should output any ACK or NACK in between the publishing. We have also done a lot of others test Posts where we occasionally did get the NACK message output (same code). Nothing changed in the code

as you can see it is totally empty sometimes which seems odd to me?

I would like to ask if this is a feature of EMA or a bug that sometimes you get back no ACK message? As our application is built around these messages to confirm or handle errors for contributions to Refinitiv.

Find more posts tagged with

java

elektron

post

elektron-sdk

refinitiv-realtime

rrt

ema-api

Accepted answers

umer.nalla

Hi @Faris

Assuming that the solicitAck(true) and postID(x) properties are set on the outgoing PostMsg, any AckMsg you receive is generated by the Provider application and EMA simply passes that onto your application via the onAckMsg() callback handler.

If you are not receiving an expect Ack(with NackCode) then the most likely reason is that the Provider application is not sending one.

Is the contribution going via RTDS (TREP) to RCC or some other Contribution engine?

I recommend you work with your Market Data team and if required the Refinitiv Real-Time Distribution System (formerly known as TREP) helpdesk to try and identify why the provider is not generating Ack(with NackCode) messages.

You can also check the low-level trace for your EMA application to confirm the presence or lack of AckMsgs on the wire. See the following post on how to enable low-level trace for EMA Java

How to enable tracing incoming/outgoing messages EMA Java receives/sends - Forum | Refinitiv Developer Community

For EMA C++ you can use the same XmlTraceToStdout or XmlTraceToFile as required.

Further details for the EMA C++ Trace related parameters can be found in the EMACPP_ConfigGuide.pdf

All comments

umer.nalla

Hi @Faris

If you are not receiving an expect Ack(with NackCode) then the most likely reason is that the Provider application is not sending one.

Is the contribution going via RTDS (TREP) to RCC or some other Contribution engine?

You can also check the low-level trace for your EMA application to confirm the presence or lack of AckMsgs on the wire. See the following post on how to enable low-level trace for EMA Java

How to enable tracing incoming/outgoing messages EMA Java receives/sends - Forum | Refinitiv Developer Community

For EMA C++ you can use the same XmlTraceToStdout or XmlTraceToFile as required.

Further details for the EMA C++ Trace related parameters can be found in the EMACPP_ConfigGuide.pdf

Faris

Hi thanks for you response, I would like to confirm that both configurations are enabled and have the settings on the outgoing messages.

Please can I clarify what you mean by the provider application?

This issue for us is something that happens sporadically and not every time, so most of the time it will work correctly and we do have an ACK or NACK message. Every 10th Post ends up in the above state with nothing returned? - This leads me to believe that the configuration and setup on our end is likely correct or we probably wouldn't get back any NACK at all (This may not be the case).

Before escalating to Refinitiv helpdesk, are you aware of any internal investigations we may be able to do to remedy this situation, and if this is likely to be something on our end, or a known issue with EMA provider application?.

umer.nalla

Hi @Faris

The Provider is whichever application receives and handles the Post Msg you send via the ADS to the ADH.

So it could be a contribution engine if contributing the data outside of your organisation or the ADH itself if you are only posting to an ADH cache service.

In terms of internal diagnostics, the above suggestion of enabling the trace and examing the low-level msg logs may possibly shed some light. Even if they don't, the output will be useful when working with the RTDS support team - as the logs will confirm if your application is behaving correctly and sending the correctly encoded PostMsgs etc.

marc.labuhn

Hi Umer again, so we have check our ADH logs and we notice a lot of logs such as these, which coincide with the events I mentioned above.


<p01.1.ads: Info: Tue May 25  09:31:45 2021>
RSSL disconnect from "Refinitiv-CC" at position "127.0.1.1/faris-XPS-13-9370" on host "faris-XPS-13-9370" using application "256" of version "unspecified|unspecified" on channel 15.
Reason: Client application did not ping.
<END>

I have tried searching online as to what is the cause of the Ping Timeout? Is there something potentially wrong in a setup which causes this? or does the EMA application have a responsibility to send some kind of periodic update to keep the connection alive, any help on this would be appreciate

umer.nalla

Hi @Faris

I am not an ADH / RTDS (TREP) expert, but based on the latest post, it appears that the ADH was disconnected from RCC.

To progress this investigation, I recommend you raise a support ticket at My.Refinitiv for the Product 'Refinitiv Contributions Channel' - so that the RCC support team can get involved and investigate further.

EXPLORE OUR SITES