Async Refresh Source Directory Response for eta3.6.4.0 causing application crash

Question

Hi Team,

We are following the example code for eta3.6.4.0, and our application is crashing on receiving the async response of source directory refresh.

in the example code for consumer class(\Eta\Applications\Examples\src\main\java\com\refinitiv\eta\examples\consumer), we have a function called 
processSourceDirectoryResp()…
this function then has a call to 
sendRequests()…
and then in sendRequests, we have a call to
sendMPRequests()…
This triggers system.exit() and app fails with the error "MarketPriceRequest.encode() failed"

We load the directory locally on the app startup. Can you help us understand the cause of this async response and how can we prevent the app to crash. Let me know if more information is required.

Jirapongse · Answer

@Viraj

eta3.6.4.0 released around five years ago (Dec 17, 2021). The latest version is RTSDK Java 2.4.0.L2 aka EMA/ETA 3.10.0.L2 aka 3.10.0.1 (May 6, 2026). You may need to upgrade the application to use the latest version.

The encoding logic resides in the application or example code, not in the ETA library itself. Therefore, you can modify the application code to capture and log any errors that occur during the encoding process.

Is there any way where we can check the buffer usage/ update the reserved buffer?
For performance reasons, ETA does not provide logging capabilities. Therefore, the application should handle error logging whenever it calls ETA functions.

if the directory is loaded on the application startup, do we still require to listen to directory updates and resend all the subscribed items?
Yes, the application should monitor directory updates so that it can track the status of the services. This information is helpful for troubleshooting issues. Additionally, as long as an item stream remains open, there is no need to re-subscribe to the same item.

It checks on subscribed service is up or not. If it is up, is it necessary for us to drop and resubscribe (SendRequest)?
As long as an item stream remains open, there is no need to re-subscribe to the same item.

Normally LSEG Developer Community Forum is for how-to/general questions. If a question seems to be more complex and requires investigation e.g. review source code, configuration, try to reproduce the problem etc.

I recommend you raise a query through the premium support service. If you are a named user of that service you should see a link "Contact Premium Support" when you are logged into the product page.

Viraj · Answer

Hi @Jirapongse,

Thanks for your reply.

Please find my answers below:

value of the return code (ret) → (-1)

step in the encoding process that causes the error. For example: → Unfortunately the sdk version we are using is not having the print lines for encoding process, so we are unable to detect the cause of failure. Neither we are able to edit the sdk code.

Are you using a batch request that subscribes to a large number of items? - I am using single request.

If so, how many items does the application subscribe to during startup? - We have dynamic subscriptions, we get a request for the subscriptions and we send it through one at a time.

The number of subscribed items may exceed the container limit or the capacity of the reserved buffer used to encode the request message. - Is there any way where we can check the buffer usage/ update the reserved buffer?

Also would like to know,

* if the directory is loaded on the application startup, do we still require to listen to directory updates and resend all the subscribed items?
* It checks on subscribed service is up or not. If it is up, is it necessary for us to drop and resubscribe (SendRequest)?

Jirapongse · Answer

@Viraj

Thank you for reaching out to us.

The processSourceDirectoryResp method processes a source directory message sent by a server. The method will check if the subscribed real-time service is up or down. If the service is up, it will call the sendRequests method to encode and send item request messages.

The MarketPriceRequest.encode() is called by the MarketPriceHandler.encodeAndSendRequest() method to encode an item request message. You may need to check the following points in the code.

* The value of the return code (ret)

2. Which step in the encoding process that causes the error. For example:

public int encode(EncodeIterator encodeIter)

    {

 …

        if (!isBatchRequest && !checkHasIdentifier())

        {

            requestMsg.msgKey().applyHasName();

            requestMsg.msgKey().name().data(itemNames.get(0));

        }

int ret = requestMsg.encodeInit(encodeIter, 0);

if (ret < CodecReturnCodes.SUCCESS)

{

System.out.println("requestMsg.encodeInit Failed: "+ret);

return ret;

}

/* encode request message payload */
        if (checkHasView() || isBatchRequest)

{

ret = encodeRequestPayload(isBatchRequest, encodeIter);

if (ret < CodecReturnCodes.SUCCESS) {

System.out.println("encodeRequestPayload Failed: "+ret);

return ret;

}

}

        ret = requestMsg.encodeComplete(encodeIter, true);
        if (ret < CodecReturnCodes.SUCCESS)

{

System.out.println("requestMsg.encodeComplete Failed: "+ret);

return ret;

}

return CodecReturnCodes.SUCCESS;

    }

Are you using a batch request that subscribes to a large number of items? If so, how many items does the application subscribe to during startup? The number of subscribed items may exceed the container limit or the capacity of the reserved buffer used to encode the request message.

EXPLORE OUR SITES