1
●1 ●1 ●3
Hi, recently we are receiving this error " failed on DCSIP (giving up): (2) No Such Record Name" whilst sending prices over the sfc API. Can someone please help?
Hello @konstantinos.kartsonakis,
In order for the community to better understand your question and try to help, please provide all the pertaining info.
For example:
Version of SFC.
What the application is doing, consuming/suscribing the RIC, insert on the RIC, publishing data on the RIC.
It seems the application was functioning as expected up till recently? Were there any code changes, entitlement changes, infra changes or upgrades, please describe.
Any other relevant details that could be helpful
-AHS
38.1k
●71 ●35 ●53
The problem should be the content of the 1000 (GV1_TEXT) and 1001 (GV2_TEXT) fields.
From the data dictionary, the size of these fields is 6.
GV1_TEXT "GV1 TEXT" 1000 NULL ALPHANUMERIC 6 GV2_TEXT "GV2 TEXT" 1001 NULL ALPHANUMERIC 6
However, in the trace data, the size of these fields is 8.
- 1e 31 30 30 30 1f 32 30 2e 36 35 30 37 36
"31 30 30 30" is FID 1000 GV1_TEXT and its data (32 30 2e 36 35 30 37 36) is 20.65076. Its size is 8 which exceeds the size defined in the data dictionary - 1e 31 30 30 31 1f 32 32 2e 39 35 30 37 36
"31 30 30 31" is FID 1001 GV2_TEXT and its data (32 32 2e 39 35 30 37 36) is 22.95076. Its size is 8 which exceeds the size defined in the data dictionary
This could cause the "(409) String Too Big" error.
data: 00000 1c 33 31 36 1d 41 54 30--30 30 30 41 32 33 44 56 |.316.AT0-000A23DV| 00010 37 3d 43 45 4e 54 1e 33--39 33 1f 32 33 2e 36 32 |7=CENT.3-93.23.62| 00020 30 1e 32 37 35 1f 32 33--2e 37 32 30 1e 39 37 35 |0.275.23-.720.975| 00030 1f 3f 1e 39 38 35 1f 35--30 30 30 1e 32 32 1f 32 |.?.985.5-000.22.2| 00040 33 2e 36 32 30 1e 32 35--1f 32 33 2e 37 32 30 1e |3.620.25-.23.720.| 00050 36 1f 32 33 2e 36 37 30--1e 31 33 1f 32 33 2e 36 |6.23.670-.13.23.6| 00060 31 30 1e 39 35 39 1f 32--33 2e 37 31 30 1e 32 38 |10.959.2-3.710.28|
00070 37 1f 31 33 3a 32 34 1e--31 31 1f 30 2e 34 38 1e |7.13:24.-11.0.48.| 00080 39 39 38 1f 30 2e 30 32--35 34 1e 31 30 30 33 1f |998.0.02-54.1003.| 00090 2d 30 2e 30 30 32 33 1e--39 39 36 1f 30 2e 39 37 |-0.0023.-996.0.97| 000a0 1c |. |
12.02.2019 14:27:10 [SEVERE]: Feb 12, 2019 2:27:10 PM com.reuters.ssl.api.SSLLogger traceData FINER: Thread: JSFC Event Thread 0 Connection 0 RECEIVE: msg_type: PT1BE_INSERT_NAK (23) eventClass: SSL.EC_INSERT_RESPONSE (2) eventType: SSL.ET_INSERT_NAK (14) serviceName: DCSIP serviceId: 2 itemName: AT0000A23F74=CENT statusState: S_NO_CHANGE (4) statusCode: IN_DENIED_BY_SRC (2) text: (409) String Too Big requestId: 7898 group: 0 requestType: 0 priorityClass: 0 priorityCount: 0 dataTypeFormat: UNKNOWN (0) dataTypeDescriptor: 0
It could be FID 1003 (GV4_TEXT).
GV4_TEXT "GV4 TEXT" 1003 NULL ALPHANUMERIC 6
The field's length defined in the data dictionary is 6 but the length of data in the tracing is 7.
1e 31 30 30 33 1f 2d 30 2e 30 30 32 33
FID 1003: Data = -0.0023
In JSFC, you can use the FidDefinition.length method to get the maximum length required to store fields with this fid.
1
●1 ●1 ●3
Hi,
to be honest I am not sure which version is it. At least older than 2012. The programm didn't change and the purpose is to contribute prices to RICS (We are sending market data eg Bid, Ask etc , for our financial certificates.
Kind regards
Kostas
23k
●22 ●9 ●14
I would compile the list of RICs that have recently started causing issues on contribution,
and check them with your local market data team, confirm the RICs remain available on your infrastructure and permissioned to the contributing user.
1
●1 ●1 ●3
Hi,
the rics are still available as they are our own emitted certificates and they are older than the problem.
PS Sorry for the delayed answer but I just returned from holidays.
Kind regards
Kostas
1
●1 ●1 ●3
as I already answered:
Hi,
to be honest I am not sure which version is it. At least older than 2012. The programm didn't change and the purpose is to contribute prices to RICS (We are sending market data eg Bid, Ask etc , for our financial certificates.
Kind regards
Kostas
the rics are still available as they are our own emitted certificates and they are older than the problem.
23k
●22 ●9 ●14
Hello @konstantinos.kartsonakis,
Are all the RICs causing the issue on contribution, or a subset of the RICs? If a subset, which RICs?
Are you contributing via MarketLink?
Would need to know the version of the API that you are using to make sure you are still supported:
39.2k
●75 ●11 ●27
@konstantinos.kartsonakis
I'm afraid it's not possible for us to help you with this issue having only the information you already provided. Would you mind responding to questions in the comment from @zoya.farberov? You should expect that we'll need a lot more detail before the root cause is identified or before we can provide any helpful suggestions.
1
●1 ●1 ●3
Hi all,
so I using the
com.reuters.sfc.inserts.general.Insert
class of JSFC 3.5.6.
No only a subset of RICs.
eg AT0000A0Z751=CENT failed on DCSIP (giving up): (409) String Too Big
Br
Hello @konstantinos.kartsonakis,
Some thoughts:
From the original error message it looked like you were trying to contribute to a non-existent RIC.
While the last error message, combined with the fact that some of the RICs contribute as expected, appears to indicate that the app attempts to contribute a fid content that is longer then the maximum length that is defined by the dictionary for that fid?
In terms of approach, if some RICs contribute, while others do not it may be helpful to try to understand what is different about the failing ones?
Hi,
thanks for the answer, for example the first idea was the description field but this is not the case as we limit all the descriptions (field = 3) to 16 characters.
There must be a way to find out the source of the problem. Eg the problematic field or the problematic value.
RIC is definitely active.
Best regards
Konstantinos Kartsonakis
The last error "failed on DCSIP (giving up): (409)" looks to be generated by your app tier?
Is your app is printing all the errors reported by JSFC?
Please include the error reported at JSFC level at the time of the failure, do you log at "processInsertFailed" ? What do you see?
Hi again,
thanks for your answer. So I simply should put to
com.reuters.utility.config.XConfigDb
object by using the
com.reuters.utility.config.XConfigDb.addVariable(String arg0, Object arg1)
the values you mentioned?
If yes where should I expect to see the relevant teracing informations?
Kind regards
Konstantinos Kartsonakis
The tracing should appear in the Java Console. It looks like:
Jan 03, 2019 9:35:30 AM com.reuters.ssl.api.SSLLogger traceData FINER: Thread: JSFC Event Thread 0 Connection 0 SEND: msg_type: (0) eventClass: SSL.EC_DEFAULT_HANDLER (0) eventType: SSL.ET_INSERT (36) serviceName: API_ELEKTRON_EPD_RSSL serviceId: 0 itemName: JPY= statusState: S_NO_CHANGE (4) statusCode: NONE (0) requestId: 2 group: 0 requestType: 0 priorityClass: 0 priorityCount: 0 dataTypeFormat: UNKNOWN (0) dataTypeDescriptor: 0 dataLength: 12 data: 00000 1c 33 31 36 1d 4a 50 59--3d 1f 30 1c |.316.JPY-=.0. |
1
●1 ●1 ●3
Hi all,
the output looks like this:
05.02.2019 17:11:30 [FINER]: Thread: JSFC Event Thread 0 Connection 0 RECEIVE: msg_type: PT1BE_INSERT_NAK (23) eventClass: SSL.EC_INSERT_RESPONSE (2) eventType: SSL.ET_INSERT_NAK (14) serviceName: DCSIP serviceId: 2 itemName: AT0000A1TJL6=CENT statusState: S_NO_CHANGE (4) statusCode: IN_DENIED_BY_SRC (2) text: (409) String Too Big requestId: 7 group: 0 requestType: 0 priorityClass: 0 priorityCount: 0 dataTypeFormat: UNKNOWN (0) dataTypeDescriptor: 0
best
Kostas
Please share the SSL insert message of AT0000A1TJL6=CENT that causes the INSERT_NAK. We should verify the content in that SSL insert message.
05.02.2019 17:11:30 [FINER]: Thread: JSFC Event Thread 0 Connection 0 SEND: msg_type: (0) eventClass: SSL.EC_DEFAULT_HANDLER (0) eventType: SSL.ET_INSERT (36) serviceName: DCSIP serviceId: 0 itemName: AT0000A1TJL6=CENT statusState: S_NO_CHANGE (4) statusCode: NONE (0) requestId: 7 group: 0 requestType: 0 priorityClass: 0 priorityCount: 0 dataTypeFormat: UNKNOWN (0) dataTypeDescriptor: 0 dataLength: 412 data:
00000 1c 33 31 36 1d 41 54 30--30 30 30 41 31 54 4a 4c |.316.AT0-000A1TJL| 00010 36 3d 43 45 4e 54 1e 33--1f 46 4c 55 20 54 4c 1e |6=CENT.3-.FLU TL.| 00020 31 32 37 31 1f 2b 34 33--2f 31 2f 35 31 35 20 32 |1271.+43-/1/515 2| 00030 30 2d 34 38 34 1e 39 36--38 1f 52 43 42 30 31 1e |0-484.96-8.RCB01.| 00040 39 39 37 1f 30 2e 31 1e--37 38 1f 41 54 30 30 30 |997.0.1.-78.AT000| 00050 30 41 31 54 4a 4c 36 1e--31 30 35 36 1f 52 43 30 |0A1TJL6.-1056.RC0| 00060 4b 56 4a 1e 31 30 35 32--1f 54 75 72 62 6f 20 52 |KVJ.1052-.Turbo R|
00070 65 74 20 4c 6f 6e 67 1e--31 30 30 30 1f 32 30 2e |et Long.-1000.20.| 00080 36 35 30 37 36 1e 31 30--30 31 1f 32 32 2e 39 35 |65076.10-01.22.95| 00090 30 37 36 1e 31 30 35 34--1f 42 6f 6e 75 73 6c 76 |076.1054-.Bonuslv| 000a0 2e 20 42 61 72 72 69 65--72 1e 33 39 33 1f 31 2e |. Barrie-r.393.1.| 000b0 34 39 30 1e 32 37 35 1f--31 2e 35 31 30 1e 39 37 |490.275.-1.510.97| 000c0 35 1f 20 1e 39 38 35 1f--35 30 30 30 1e 32 32 1f |5. .985.-5000.22.| 000d0 31 2e 34 39 30 1e 32 35--1f 31 2e 35 31 30 1e 36 |1.490.25-.1.510.6|
000e0 1f 31 2e 35 30 30 1e 31--39 1f 31 2e 35 30 30 1e |.1.500.1-9.1.500.| 000f0 39 36 31 1f 31 2e 35 32--30 1e 32 38 35 1f 30 38 |961.1.52-0.285.08| 00100 3a 30 39 1e 32 31 1f 31--2e 34 37 30 1e 39 36 33 |:09.21.1-.470.963| 00110 1f 31 2e 34 39 30 1e 37--39 1f 30 34 20 46 65 62 |.1.490.7-9.04 Feb| 00120 20 32 30 31 39 1e 31 33--1f 31 2e 34 37 30 1e 39 | 2019.13-.1.470.9| 00130 35 39 1f 31 2e 34 39 30--1e 32 38 37 1f 30 38 3a |59.1.490-.287.08:| 00140 31 34 1e 31 32 1f 31 2e--35 30 30 1e 39 35 37 1f |14.12.1.-500.957.|
1
●1 ●1 ●3
Hi,
just to elaborate the issue is still present and unfortunately from the tracing we were not able to find any helpful information.
Best regards
Kostas
