@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?
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
Hi @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?
You can set *ipcTraceFlags to 11 in the JSFC configurations in order to enable data tracing in JSFC.
*ipcTraceFlags : 11
With the data tracing, we may be able to identify the problem.
Hi, partially yes, 409 is the servicename and the "String Too Big" is the result of the Insert.text() method on the processInsertFailed(Insert insert) callback. Is there any performance issues when we set this flags?
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?
The tracing should appear in the Java Console. It looks like:
Jan 03, 2019 9:35:30 AM com.reuters.ssl.api.SSLLogger traceDataFINER: Thread: JSFC Event Thread 0Connection 0SEND: msg_type: (0)eventClass: SSL.EC_DEFAULT_HANDLER (0)eventType: SSL.ET_INSERT (36)serviceName: API_ELEKTRON_EPD_RSSLserviceId: 0itemName: JPY=statusState: S_NO_CHANGE (4)statusCode: NONE (0)requestId: 2group: 0requestType: 0priorityClass: 0priorityCount: 0dataTypeFormat: UNKNOWN (0)dataTypeDescriptor: 0dataLength: 12data: 00000 1c 33 31 36 1d 4a 50 59--3d 1f 30 1c |.316.JPY-=.0. |
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.
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.
