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?
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).
Thanks for your help on this matter. For this to work the publisher should call indicateResync().
I will give it a try.
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!
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 When the application first received data after requesting data, does it contain the requested fields with empty value or those requested fields will arrive in a later updates?
@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 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
