Hi @yd.liu

If a connection is lost or interrupted, the server will send the most recent values for all fields for any instruments you are subscribed to. This is to ensure the consumer has the latest values - in case there have been any changes to any of the fields during the connection down period.

The above type of message is normally flagged as an Unsolicited Refresh type message - so you can differentiate it from a normal market activity Update message which usually contains normally market activity updates.

Hi @yd.liu

As your query concerns content rather than an API related matter, the best way to resolve this would be to raise a Content type ticket at My.Refinitiv - so that you can discuss your concerns with a Content expert for the particular exchange or provider that you are consuming data from.

This forum is generally monitored by API specialists and not content specialists.

I have created a ticket for you ref:09464670 and someone from the content team should be in touch soon.

In future, for a more timely response, please feel free to raise a content directly at My.Refinitiv.

Hi Refinitiv,

Today I noticed a new case of duplicated data. It happens when the service is restarted. The sample log is:

CODE_INFO: Connection ping timeout

CODE_INFO: Waiting for service IDN_XXXXXX UP. Item recovery in progress...

CLASS_SUBSCRIBER: STATE_OK

CODE_INFO: Service UP

Is there a way to disable the feature of send last tick when the service is up? Because this may cause duplicated ticks.

Hi @yd.liu

Unsolicited Refresh is the message type - not a particular field name. It would be an attribute of the incoming message.

Please confirm which of our APIs you are using so that I can help you in extracting the message type from any incoming message. If you are using an internally developed wrapper for one of our APIs you will need to refer back to your internal developers for guidance.

If you are unsure which API - please provide names of the jar files etc so I can try and identify the API.

Hi @yd.liu

In case your wrapper developer is not original author or is unsure what they are looking for the following may help:

If they are using our legacy data format,then the type of information they would be looking for in thecode would be something like:

getMarketDataMsgType() == MarketDataItemEvent.UNSOLICITED_IMAGE or MarketDataItemEvent.IMAGE

Other values can be UPDATE off course, but also CORRECTION, CLOSING_RUN etc

If they are using the more recent data format they would be looking for something like:

getRespTypeNum() == OMMMsg.RespType.SOLICITED and OMMMsg.RespType.UNSOLICITED

A brief explanation from the documentation:

OMM Message Type: Refresh Response

Provided as an initial response or when an upstream source requires a data resynchronization point, a REFRESH_RESP message type contains payload information along with state, QoS, permissioning, and group information. If provided as a response to a request message, this is referred to as a solicited refresh. If some kind of information change occurs, possibly an error detected on a stream, an upstream provider can generate a refresh response message to downstream consumers - this is referred to as an unsolicited refresh.