question

Upvotes
Accepted
Frederic avatar image
37 ●1 ●1 ●6

RTO EMA C++ consumer destructor 'Segmentation fault (core dumped)'

Considering this code snippet:
1.png

For the destructor method, it got the following 'Segmentation fault (core dumped)' error:

2.png

So the question is

1) is that allow to call the destructor (to cleanup) of the consumer and then create a new one theoretically? And why we see those error?

2) For EMA C++, is that true the handler (onRefreshMsg, onStatusMsg,...,) logic runs in a separate thread other that the 'main' thread?
3) Is there any case that EMA cannot recover the connection and quit the application (even set the attemptLimit = -1)?

4) In the case of Login Stream CLOSED due to some issue, does the application need to destroy the old consumer and create a new one, how to do that in the onStatusMsg method implementation?

ema-apirrtoc++
1.png (37.9 KiB)
2.png (268.9 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.

2 Answers

Upvotes
Accepted
umer.nalla avatar image
20.3k ●73 ●10 ●20

Hi @Frederic

As per your final question above, on a Force Logout from Dacs where the Login Stream is closed, you would need to delete the OmmConsumer and create again to initiate a new connection + login etc.


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
umer.nalla avatar image
20.3k ●73 ●10 ●20

Hi @Frederic

Firstly, I don't understand why the code above is calling the destructor explicitly - I am not a hardcore C++ developer - but I have always been advised that we should never call the destructor explicitly.
I tested an EMA Example on Linux (WSL) and If I call the destructor explicitly as in the code snippet above, I also see a Segmentation fault. If, however, I delete the OmmConsumer instance then I do not see the segmentation fault.

The event handlers do run in a separate thread to the main application thread.

If ReconnectAttemptLimit is set to -1, it should continue to try and connect indefinitely - unless of course, the main() function exits (e.g. in most of the EMA examples we have a 60s time limit).

If the Login Stream is closed then all streams are closed and the connection is closed, so they would need to create a new OmmConsumer. In terms of deleting and creating a new OmmConsmer - this should be down to standard C++ coding and the developer would need to implement the appropriate strategy in their code. For example, the EMA example 410 creates multiple OmmConsumer by creating a separate class called ConsumerManager - so even here the developer could have a separate class that handles creating and deleting an OmmConsumer on demand.




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.

Frederic avatar image Frederic

Thank you for the helpful information, I will have a check

Frederic avatar image Frederic

In such case of Login Stream closed not intended (maybe due to connection issue?), will the EMA auto recover that?

Frederic avatar image Frederic

Take the 'Force Logout from DACS' example (https://community.developers.refinitiv.com/questions/87314/rto-force-logout-from-dacs-in-the-ema-login-domain.html), the connection was closed by server.
In such case will the EMA recover the connection? (maybe this question will go to the Reactor implementation)

Or we should delete the consumer then recreate?
(Looks like the client encountered some issue that duplicated messages are received... do not have much detail on that.)

Click below to post an Idea Post Idea