JSFC3.5.6: RTRecord is active but has no data

Using JFSC 3.5.6 an RTRecord reports its status as active and hasData() returns true.

However sequential access of the data on the record in processRecordSync shows there are no fields. Calling hasMoreElements on the enumeration instance returned by the record returns false.

Are there any reasons why this might be the case?

Find more posts tagged with

trep

elektron

refinitiv-realtime

Accepted answers

Nipat Kunvutipongsak

@Kwame.Asiedu-Saforo,

In the situation that a publisher sends additional non-existing

fields to a JSFC application later, it must call indicateResync() in case of SFC Market Data interface (or send a REFRESH message with CLEAR_CACHE flag if the data source application is OMM Provider) to send a Verify_Record (318) to re-synchronize record again.

Here this is the example of the raw message.

Mar 05, 2018 6:20:23 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1_ITEM_IMAGE (35)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_IMAGE (0)
serviceName: API_ADH_NI_PUB
serviceId: 32107
itemName: TRI.N
statusState: S_OK (0)
statusCode: NONE (0)
text: Initial.
requestId: 1
group: 1
requestType: 0
priorityClass: 0
priorityCount: 0
nextName: TRI.N
prevName: TRI.N
dataTypeFormat: DF_MARKETFEED_RECORD (2)
dataTypeDescriptor: 5
dataLength: 61
data: 
00000   1c 33 34 30 1f 58 58 1d--54 52 49 2e 4e 1f 1f 31  |.340.XX.-TRI.N..1|
00010   1e 33 1f 53 69 6d 70 6c--65 50 75 62 20 54 52 49  |.3.Simpl-ePub TRI|
00020   2e 4e 1e 32 32 1f 31 2e--30 30 1e 33 30 1f 31 31  |.N.22.1.-00.30.11|
00030   2e 30 30 1e 33 31 1f 31--31 2e 32 30 1c           |.00.31.1-1.20.   |

processRecordSync 
rec.hasData(): true
SYMBOL= TRI.N
BID= 1.00
ASK= N/A


Mar 05, 2018 6:20:27 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1_BE_ITEM_UPDATE (41)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_UPDATE (1)
serviceName: API_ADH_NI_PUB
serviceId: 32107
itemName: TRI.N
statusState: S_NO_CHANGE (4)
statusCode: NONE (0)
group: 0
requestType: 0
priorityClass: 0
priorityCount: 0
dataTypeFormat: UNKNOWN (0)
dataTypeDescriptor: 0
dataLength: 42
data: 
00000   1c 33 31 36 1f 58 58 1d--54 52 49 2e 4e 1f 35 1e  |.316.XX.-TRI.N.5.|
00010   32 32 1f 31 2e 34 30 1e--33 30 1f 31 31 2e 34 30  |22.1.40.-30.11.40|
00020   1e 33 31 1f 31 31 2e 36--30 1c                    |.31.11.6-0.      |

processUpdate called: updateType=Tick
processFieldUpdate called:
processFieldUpdate called: TRI.N: BID= 1.40
processFieldUpdate called: TRI.N: ASK= N/A
processUpdateComplete called: Initial.
FIELD LIST = { 22, 30, 31 }

Mar 05, 2018 6:20:28 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1_ITEM_IMAGE (35)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_IMAGE (0)
serviceName: API_ADH_NI_PUB
serviceId: 32107
itemName: TRI.N
statusState: S_OK (0)
statusCode: NONE (0)
text: Resynchronized
group: 1
requestType: 0
priorityClass: 0
priorityCount: 0
nextName: TRI.N
prevName: TRI.N
dataTypeFormat: DF_MARKETFEED_RECORD (2)
dataTypeDescriptor: 5
dataLength: 69
data: 
00000   1c 33 31 38 1f 58 58 1d--54 52 49 2e 4e 1f 1f 31  |.318.XX.-TRI.N..1|
00010   1e 33 1f 53 69 6d 70 6c--65 50 75 62 20 54 52 49  |.3.Simpl-ePub TRI|
00020   2e 4e 1e 32 32 1f 31 2e--36 30 1e 32 35 1f 31 2e  |.N.22.1.-60.25.1.|
00030   38 30 1e 33 30 1f 31 31--2e 36 30 1e 33 31 1f 31  |80.30.11-.60.31.1|
00040   31 2e 38 30 1c                                    |1.80.            |

processRecordResync called: Resynchronized
processResyncComplete called: Resynchronized
A field:ASK does exist now!

processUpdate called: updateType=Tick
processFieldUpdate called: TRI.N: BID= 1.60
processFieldUpdate called: TRI.N: ASK= 1.80
processUpdateComplete called: Resynchronized
FIELD LIST = { 22, 25, 30, 31 }

Therefore, this situation requires two actions to make JSFC receives additional fields.

1. New fields must come with Verify_Record (318)

2. A JSFC subscriber application should check additional fields (in the RTRecordClient.processResyncComplete() callback and call RTRecord.addClient() for those new fields as well to register their further updates).

All comments

Nipat Kunvutipongsak

Hello @Kwame.Asiedu-Saforo,

My assumption regarding this situation is that the application uses partial record fields instead of full record, but the instrument doesn't give you the desired fields requested. So, there is no field appeared.

Partial Field Record Request:

String[] fieldNames = {"ASK", "ASKSIZE"}
RTRecordService.rtRecord("instrument", fields);

Full Record Request:

RTRecordService.rtRecord("instrument");

If the application connects to P2PS/ADS machine, I suggest you enable data-tracing parameter (ipcTraceFlags = 31) to reveal the incoming data printed by JSFC's underlying layer.

Here this is the programmatic approach example with ipcTraceFlags:

 XConfigDb configDb = new XConfigDb();
 configDb.addVariable("serverType", "sapi");
 configDb.addVariable("serverList", "192.168.27.46");
 configDb.addVariable("portNumber", "8101");
 configDb.addVariable("mountTrace", "true");
 configDb.addVariable("ipcTraceFlags", "31");
 configDb.addVariable("serviceName", "API_ATS1_4");
 configDb.addVariable("symbol", "NIPAT_ATS.BK");
 configDb.addVariable("fieldName", "ASK");
 configDb.addVariable("dictFromFile", "true");
 configDb.addVariable("fid_file_path", "Z:/API/dictionaries/4.20.26_TREP_16.81.service_pack/Setup/TREP/win32/etc/appendix_a");
 configDb.addVariable("enum_file_path", "Z:/API/dictionaries/4.20.26_TREP_16.81.service_pack/Setup/TREP/win32/etc/enumtype.def");
 configDb.addVariable("enablePermission", "true");
 configDb.addVariable("position", "customPosition");
 configDb.addVariable("application", "254");
 configDb.addVariable("username ", "ice");
 configDb.addVariable("traceSelector ", "DEBUG");
 return configDb;

This is an excerpt result output:

Feb 22, 2018 6:48:04 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1BE_IMAGE (2)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_IMAGE (0)
serviceName: API_ATS1_4
serviceId: 4
itemName: NIPAT_ATS.BK
statusState: S_OK (0)
statusCode: NONE (0)
requestId: 1
group: 3
flags: 2
requestType: 0
msgflags: 1
priorityClass: 0
priorityCount: 0
dataTypeFormat: DF_MARKETFEED_RECORD (2)
dataTypeDescriptor: 0
dataLength: 85
data: 
00000   1c 33 34 30 1f 58 58 1d--4e 49 50 41 54 5f 41 54  |.340.XX.-NIPAT_AT|
00010   53 2e 42 4b 1f 30 1f 31--1e 32 1f 36 37 1e 33 1f  |S.BK.0.1-.2.67.3.|
00020   4e 49 50 41 54 5f 41 54--53 2e 42 4b 1e 32 35 39  |NIPAT_AT-S.BK.259|
00030   1f 32 30 39 1e 31 36 1f--32 32 20 46 45 42 20 32  |.209.16.-22 FEB 2|
00040   30 31 38 1e 35 1f 31 32--3a 31 34 1e 32 32 1f 2b  |018.5.12-:14.22.+|
00050   30 2e 32 32 1c                                    |0.22.            |

processRecordSync called:

According to the response above, it doesn't have the ASK/ASKSIZE fields, so processRecordSync will do nothing.

In other hand, if I request BID instead of ASK/ASKSIZE, the output of processRecordSync will be as follows:

processRecordSync called: NIPAT_ATS.BK: BID= +0.22

The image above demonstrates that the NIPAT_ATS.BK record data contain only BID.

The application on the left tried to request a partial field (only BID), and it got data while the application on the right requested only ASK and printed nothing in the processRecordSync callback method.

Hope this helps!

Kwame.Asiedu-Saforo

@Nipat
Kunvutipongsak thanks for your response re possible cause and tracing. I will set the trace up to see what is actually happening.

The scenario we have is that we are requesting data for a currency pair published by a third party source provider to TREP. We know that the data is published to TREP as and when it is available. If initially there is no data for our partial request on a currency pair, we expect that when the provider starts publishing the data, the fields requested will be dynamically made available to us using the current RTRecordClient instance we have. Currently we have to create a new RTRecordClient, get a record instance for the currency pair from the service and then reqister ourselves with the record in order to receive the data when is it published.

Is there another way round this problem?

Thanks

Kwame

Kwame.Asiedu-Saforo

Hello@Nipat Kunvutipongsak thanks for your response re possible cause and tracing.

The scenario we have is that we are requesting data for a currency pair published by a third party source provider to TREP. The data is published to TREP as and when it is available. If there is no data for our initial partial request we expect that when the provider starts publishing the data, the requested fields will automatically be made available to us using the existing RTRecordClient instance. Currently we have to create a new RTRecordClient. Is there another way to resolve this issue.

Kwame.Asiedu-Saforo

@Nipat Kunvutipongsak When we receive the first callback in processRecordSync, calling hasMoreElements on the Enumeration instance got from the record returns false. We get updates later on by re-requesting the same data via a new instance of the RTRecordClient. We suspect this is because the data is later on made available by the provider. We were hoping not to have to re request but be automatically updated.

Nipat Kunvutipongsak

@Kwame.Asiedu-Saforo,

In the situation that a publisher sends additional non-existing

Here this is the example of the raw message.

Mar 05, 2018 6:20:23 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1_ITEM_IMAGE (35)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_IMAGE (0)
serviceName: API_ADH_NI_PUB
serviceId: 32107
itemName: TRI.N
statusState: S_OK (0)
statusCode: NONE (0)
text: Initial.
requestId: 1
group: 1
requestType: 0
priorityClass: 0
priorityCount: 0
nextName: TRI.N
prevName: TRI.N
dataTypeFormat: DF_MARKETFEED_RECORD (2)
dataTypeDescriptor: 5
dataLength: 61
data: 
00000   1c 33 34 30 1f 58 58 1d--54 52 49 2e 4e 1f 1f 31  |.340.XX.-TRI.N..1|
00010   1e 33 1f 53 69 6d 70 6c--65 50 75 62 20 54 52 49  |.3.Simpl-ePub TRI|
00020   2e 4e 1e 32 32 1f 31 2e--30 30 1e 33 30 1f 31 31  |.N.22.1.-00.30.11|
00030   2e 30 30 1e 33 31 1f 31--31 2e 32 30 1c           |.00.31.1-1.20.   |

processRecordSync 
rec.hasData(): true
SYMBOL= TRI.N
BID= 1.00
ASK= N/A


Mar 05, 2018 6:20:27 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1_BE_ITEM_UPDATE (41)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_UPDATE (1)
serviceName: API_ADH_NI_PUB
serviceId: 32107
itemName: TRI.N
statusState: S_NO_CHANGE (4)
statusCode: NONE (0)
group: 0
requestType: 0
priorityClass: 0
priorityCount: 0
dataTypeFormat: UNKNOWN (0)
dataTypeDescriptor: 0
dataLength: 42
data: 
00000   1c 33 31 36 1f 58 58 1d--54 52 49 2e 4e 1f 35 1e  |.316.XX.-TRI.N.5.|
00010   32 32 1f 31 2e 34 30 1e--33 30 1f 31 31 2e 34 30  |22.1.40.-30.11.40|
00020   1e 33 31 1f 31 31 2e 36--30 1c                    |.31.11.6-0.      |

processUpdate called: updateType=Tick
processFieldUpdate called:
processFieldUpdate called: TRI.N: BID= 1.40
processFieldUpdate called: TRI.N: ASK= N/A
processUpdateComplete called: Initial.
FIELD LIST = { 22, 30, 31 }

Mar 05, 2018 6:20:28 PM com.reuters.ssl.api.SSLLogger traceData
FINER: 
Thread: JSFC Event Thread 0
Connection 0
RECEIVE: 
msg_type: PT1_ITEM_IMAGE (35)
eventClass: SSL.EC_DATA (1)
eventType: SSL.ET_ITEM_IMAGE (0)
serviceName: API_ADH_NI_PUB
serviceId: 32107
itemName: TRI.N
statusState: S_OK (0)
statusCode: NONE (0)
text: Resynchronized
group: 1
requestType: 0
priorityClass: 0
priorityCount: 0
nextName: TRI.N
prevName: TRI.N
dataTypeFormat: DF_MARKETFEED_RECORD (2)
dataTypeDescriptor: 5
dataLength: 69
data: 
00000   1c 33 31 38 1f 58 58 1d--54 52 49 2e 4e 1f 1f 31  |.318.XX.-TRI.N..1|
00010   1e 33 1f 53 69 6d 70 6c--65 50 75 62 20 54 52 49  |.3.Simpl-ePub TRI|
00020   2e 4e 1e 32 32 1f 31 2e--36 30 1e 32 35 1f 31 2e  |.N.22.1.-60.25.1.|
00030   38 30 1e 33 30 1f 31 31--2e 36 30 1e 33 31 1f 31  |80.30.11-.60.31.1|
00040   31 2e 38 30 1c                                    |1.80.            |

processRecordResync called: Resynchronized
processResyncComplete called: Resynchronized
A field:ASK does exist now!

processUpdate called: updateType=Tick
processFieldUpdate called: TRI.N: BID= 1.60
processFieldUpdate called: TRI.N: ASK= 1.80
processUpdateComplete called: Resynchronized
FIELD LIST = { 22, 25, 30, 31 }

Therefore, this situation requires two actions to make JSFC receives additional fields.

1. New fields must come with Verify_Record (318)

Kwame.Asiedu-Saforo

@Nipat Kunvutipongsak

Thanks for your help on this matter. For this to work the publisher should call indicateResync().

I will give it a try.

EXPLORE OUR SITES