Duplicate ticks of .ZK names after market is closed

Hi Refinitiv,

I am using a java package provided by the firm and its data source is RMDS/TREP. When I run the application to collect intraday ticks, some ticks are received unexpectedly.

E.g. RIC: 000002.ZK

The market is closed at 3 pm HKT while there is a duplicated tick at about 4:30 pm HKT. The price, volume, and trade time are exactly the same with the close price tick received at 3 pm HKT.

How to determine if the tick is not a real-time tick? Like the duplicated tick, or when the application is launched at 10 pm, the last tick will be received. One way is to compare the trade time with the actual machine time, but it is not elegant.

Meanwhile, I can see many ticks at about 6:49 am before the market is open. They have no price fields which is easy to filter out. However, could you explain what is the aim of these ticks?

Thank you in advance.

Find more posts tagged with

trep

data

elektron

refinitiv-realtime

Accepted answers

umer.nalla

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.

All comments

umer.nalla

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.

yd.liu

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.

umer.nalla

Hi @yd.liu

yd.liu

Hi Refinitiv,

I think Unsolicited Refresh is exactly what I want. Can I ask how to get this from a tick message? like a field ID or field name.

I searched 'Unsolicited' in the enumtype.def file while it is not found.

umer.nalla

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.

yd.liu

Hi Refinitiv,

I found the MESSAGE_TYPE in the internal wrapper package. It has two kinds of values: IMAGE and UPDATE. I can ask the developer of this package for the details.

Thanks again for your helpful suggestions.

umer.nalla

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.

EXPLORE OUR SITES