Null Payload in OmmMsg

Jaydipkumar.pansuriya

Hi Team,

We are migrating from RFA 7.6 to 8.1. We recently found a scenario in which Payload from OmmMsg was null, causing NullPointerException. Below is the snippet that caused the issue. From which we already verify that event and msg are not null.

byte[] data = ommItemEvent.getMsg().getPayload().getBytes()

Also this scenario was never previously observed where payload can be null.

So I want to know that in which scenario we can get null payload like any event, connection issue (which I don't see on logs), or any issue on Reuters side.

Thanks.

umer.nalla

Hi @Jaydipkumar.pansuriya

You can receive message with no payload - e.g. a StatusMsg would have no payload.

Are you trying to extract a Payload from a StatusMsg?

As demonstrated in many of the RFA examples you should always check if a payload is blank before attempting to access the data e.g.

if ( respMsg.getPayload().isBlank() )

Jaydipkumar.pansuriya

https://community.developers.refinitiv.com/discussion/comment/55418#Comment_55418

I am getting this issue after all basic checks like Response MsgType is OMMMsg.MsgType.REFRESH_RESP & RDMMsgTypes is RDMMsgTypes.MARKET_PRICE. I have never seen this issue while getting payload from a REFRESH response.

umer.nalla

https://community.developers.refinitiv.com/discussion/comment/55495#Comment_55495

Hi @Jaydipkumar.pansuriya

Are you consuming Refinitiv Elektron data or some internally published data?

Please provide a IPCTrace file for when the above occurs so we can investigate further. For RFA Java you will need to set the ipcTrace Flag in your config for the RSSL connection you are using e.g.

<node name="consConnection">
      <map>
           <entry key="connectionType" value="RSSL"/>
           <entry key="serverList" value="<yourServer>"/>
           <entry key="portNumber" value="14002"/>
           <entry key="mountTrace" value="true"/>
           <entry key="ipcTraceFlags" value="7"/>
           <entry key="logFileName" value="rfa.log"/>
      </map>
 </node>   

If the problem is not easily recreatable and the trace file ends up being very large, please extract the Response message and corresponding Request message which causes the above exception. You can identify the Request message from service + instrument names. Make a note of the streamID for the Request and find the Response Message with the same StreamID.