@konstantinos.kartsonakis
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.
This could cause the "(409) String Too Big" error.
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
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
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.
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.
as I already answered:
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:
API Obsolescence List
@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 faberov? 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.
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
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?
the output looks like this:
05.02.2019 17:11:30 [FINER]:Thread: JSFC Event Thread 0Connection 0RECEIVE:msg_type: PT1BE_INSERT_NAK (23)eventClass: SSL.EC_INSERT_RESPONSE (2)eventType: SSL.ET_INSERT_NAK (14)serviceName: DCSIPserviceId: 2itemName: AT0000A1TJL6=CENTstatusState: S_NO_CHANGE (4)statusCode: IN_DENIED_BY_SRC (2)text: (409) String Too BigrequestId: 7group: 0requestType: 0priorityClass: 0priorityCount: 0dataTypeFormat: UNKNOWN (0)dataTypeDescriptor: 0
best
just to elaborate the issue is still present and unfortunately from the tracing we were not able to find any helpful information.
Best regards
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 0Connection 0SEND:msg_type: (0)eventClass: SSL.EC_DEFAULT_HANDLER (0)eventType: SSL.ET_INSERT (36)serviceName: DCSIPserviceId: 0itemName: AT0000A1TJL6=CENTstatusState: S_NO_CHANGE (4)statusCode: NONE (0)requestId: 7group: 0requestType: 0priorityClass: 0priorityCount: 0dataTypeFormat: UNKNOWN (0)dataTypeDescriptor: 0dataLength: 412data:
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|
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 traceDataFINER:Thread: JSFC Event Thread 0Connection 0RECEIVE:msg_type: PT1BE_INSERT_NAK (23)eventClass: SSL.EC_INSERT_RESPONSE (2)eventType: SSL.ET_INSERT_NAK (14)serviceName: DCSIPserviceId: 2itemName: AT0000A23F74=CENTstatusState: S_NO_CHANGE (4)statusCode: IN_DENIED_BY_SRC (2)text: (409) String Too BigrequestId: 7898group: 0requestType: 0priorityClass: 0priorityCount: 0dataTypeFormat: UNKNOWN (0)dataTypeDescriptor: 0
Looks fine now! Please close the case.
