REFRESH_RESP and or REFRESH_COMPLETE
Hi
We see that USDTRY implied liquidities published by FMS aren’t traversing TREP correctly.
The message is large so is split over 3 TREP packets – we expect to receive a packet of REFRESH_RESP without REFRESH_COMPLETE for the first two packets followed by as REFRESH_RESP and REFRESH_COMPLETE. At which point we can correctly process the message.
On the non working version we get a single packet from TREP with REFRESH_RESP and REFRESH_COMPLETE set. In that packet we have a handful of tenors that are correct but also have to filter out some bad tenors.
We are currently using RFA 7.2.0, Note: this is a cascaded service
Hello @jeff.waterman,
The fragmentation of a large message may be introduced by the publisher/source or by TREP.
If you are sure that the message is getting fragmented incorrectly by TREP(?) then the issue looks to be a configuration of a TREP issue, unrelated to API, and then it is much better handled by our Helpdesk support organization. THIS forum is dedicated to APi related questions and discussions. In this case, we can help raise a support case on your behalf?
However, in my view, a publisher, especially a custom source. has more opportunity to introduce an error into fragmenting, as it fully implements it, setting "REFRESH_COMPLETE" or not setting it fully at the discretion of the app developer.
Are you consuming from a direct feed? Custom publisher? Elektron? If the later, and you provide an example RIC(s), I can test what I receive on the RIC on our testbed, with a supported version of RFA ( the supported versions of RFA is 7.6.2 and 8, so if this turns out to be an API issue, the issue will need to be reproduced on a supported version of the API).
Hello @jeff.waterman
You can find the supported RFA versions with which infrastructure and OS compiler versions from The API Compatibility Matrix . For upgrading RFA Java, you can refer to my answer in this question.