question

Upvotes
Accepted
1 0 0 3

Why RFA java application crashed when subscribed ESc1 data enhancement activity of FID 32482?

esc1.txt

There was data enhancement activity of FID 32482 – Accumulated Eligible Trade Volume (ELG_ACVOL) for Chicago Mercantile Exchange Futures and Options instruments (ref. DN100758) on Nov-26.

My Java VM was crashed when my application subscribed ESc1. I have another application running same RFA API has no issue when not getting ESc1 data. Why it crashed my Java application?

We got similar data updates of ESc1 (as file esc1.txt enclosed in this thread) from data feed. FID ELG_ACVOL keep repeating itself in a single data update message.

API using: RFA java 7.0.1.L1

treprfarfa-api
esc1.txt (101.0 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvote
Accepted
4.4k 10 6 9

Hi @hlai

This was an issue on Refinitiv side and the data change from DNDN100758 has been rolled back.

Please see the <ALERT31> and <ALERT38> for more information.

As per our Content Team, most likely we will update the DN with a new effective date early next week.


alert31.jpg (122.8 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
20.3k 73 10 20

Hi @hlai

Firstly, please note that the version of RFA Java you are using is no longer supported.

You should be using RFA 7.6.1.L2 as a minimum or ideally v8.x.

You can download these versions from RFA Java Downloads

In the meantime, a few things:

  1. you say your JVM crashes - any further detail on that?
  2. The attached output - is that from the same application that causes the JVM crash or some other test example you are using?
  3. Please subscribe to the same instrument using one of the supplied RFA Consumer examples to see if the problem persists.
  4. If the RFA consumer example also crashes, then please try with a newer version of the API and confirm if the problem persist.

In the meantime I will check with the data team to check if there was a problem with the new FID on that instrument - since the DN100758 was rolled out.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
1 0 0 3

@Warat B. We would like to know why update pattern triggered by data change of the DN caused RFA java API VM crashed.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
1 0 0 3

@Umer Nalla,

The attached output was output of MDSubDemo, one of RFA example program.

As we observed that there were field ELG_ACVOL repeated 1940 times in a single data update message, what is the impact to RFA API application?

On Nov-26, we have multiple RFA applications running. Those subscribed instruments of CME futures instruments that encountered repeated field ELG_ACVOL in data update HAS issue. Those without subscription of CME instruments HAS NO issue.

Another observation, ELG_ACVOL (FID 32482) was not existed in appendix_a file of RFA application. The crash was not observed after we added ELG_ACVOL (FID 32482) in appendix_a. Therefore, we took it as workaround solution before data feed stopped the repeated field ELG_ACVOL update pattern. Can we know why?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
4.4k 10 6 9

@hlai

It is possible that the ELG_ACVOL (FID 32482) that you added does not match the actual definition.

So first of all, please update the appendix_a files to the latest version.

You can get the appendix_a from RFA java 7.6.1.L2 package. The file is inside \etc\Marketfeed folder.

Another possibility is that your application crash because of the repeating field.

During the Nov-26, The Elektron head-end sent update messages that have repeating ELG_ACVOL fields, as you have captured in esc1.txt. The repeating fields is an error on the server side. But to avoid crashing in any future incident, please make sure that the application can handle the repeating field.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
1 0 0 3

@Warat B.

"...The repeating fields is an error on the server side. But to avoid crashing in any future incident, please make sure that the application can handle the repeating field."

1. That is our query. Why repeating fields caused RFA java API issue or crash?

2. Do you mean the repeating field update issue would not be found after we upgrade to RFA java 7.6.1.L2 even the field not specified in appendix_a?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
4.4k 10 6 9

@hlai

  1. As I said, it could be because you are using an outdated dictionary and so the RFA API cannot apply the dictionary, or because the application cannot handle the fields after getting them from API.

    The RFA API just iterate through fields -> apply dictionary -> and then pass the data to the application. It never checked if the fields are repeated or not. So I suggested checking the dictionary and your application code.

    You say your JVM crashes - any further detail?
  2. No, what I mean is the head-end server sent repeating field by mistake. The repeating field update is not RFA API specific issue. It's a global issue effect every product.
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Click below to post an Idea Post Idea