Application crash in rfa::common::EventQueueImpl::dispatch(long) from libRFA_Common.so

mktdata
mktdata Contributor
edited September 25 in RFA

Hi Team,

We are using RFA version 8.2.3 C++ to consume market data.

libRFA_Common.so [version.c VERSION 8.2.3 RELEASE (Internal Node: rfaut8.2.3.L1)]

There is one scenario we are performing, below are the steps,

  1. Subscribe to a symbol/security AAPL (subscription is still open)
  2. Resubscribe to same security, which will
    1. Delete the previously created OMM client for AAPL
    2. create new OMM client again

In this scenario we observed a application crash rfa::common::EventQueueImpl::dispatch(long) from libRFA_Common.so

call stack information in the core file :

0x00002ab2002b10dc in rfa::common::EventQueueImpl::dispatch(long) () from /home/flexsys/flex/bin/libRFA_Common.so
0x000000000072bf6c in RFAFlex::DataThread::Loop (this=0x121cc60 <RFAFlex::SingletonRFAFlex::DataThread::GetInstance()::myInstance>) at marketdata/Reuters_RFA/RFADataThread.cpp:637
0x00000000007990ea in RFAFlex::RFAThread::Run (pVoid=0x121cc60 <RFAFlex::SingletonRFAFlex::DataThread::GetInstance()::myInstance>) at marketdata/Reuters_RFA/RFAThread.cpp:32

I saw some crash related questions, and the resolution is to upgrade the libs. I want to ask is the issue still persist in the libs which are using? Or the root cause is something else

https://community.developers.refinitiv.com/discussion/29000/application-crashes-in-rfa-lib-files-c-linux
Tagged:

Answers

  • Jirapongse
    Jirapongse ✭✭✭✭✭

    @mktdata

    Thank you for reaching out to us.

    You need to check the 6.4.1.5 Closing Event Stream section in the RFA developer guide.

    The application closes the stream via unregisterClient() call to RFA. In this case, RFA might dispatch additional events that were in flight due to race condition. To determine the point at which RFA closes an event stream, an application should use completion events. In this case, the application may add an additional case statement in the processEvent() method. The completion event enumeration is ComplEventEnum, available in the Common Package.

    In short, if the application calls the unreisterClient to close stream, it must wait for a completion event or a closed stream event before destroying an associated OMM client.

    createOMMConsumer() also accepts an optional second parameter which specifies whether or not completion events should be sent, which by default is false. To enable the completion events, the second parameter must be set to true.

    OMMConsumer * 	createOMMConsumer (const rfa::common::RFA_String &name, bool wCompEvents=false)=0

    If this doesn't solve this issue, you need to upgrade the application to latest version (RFA 8.2.5.L3) or contact the API support team via Contact Premium Support to investigate this issue.

  • mktdata
    mktdata Contributor
    https://community.developers.refinitiv.com/discussion/comment/128079#Comment_128079

    Thank you for your quick response. One follow up question,

    Let's say while doing subscription:

    pOMMConsumer->registerClient( pEventQueue, &ommItemIntSpec, *this, NULL );

    we encountered a exception. Then in that case do we receive event ComplEventEnum with isEventStreamClosed = true or any other event?

    If yes, We need to delete associated omm client after that.

    But if no, then is it fine to delete the omm client immediately?

  • Jirapongse
    Jirapongse ✭✭✭✭✭

    The application must delete an omm client after the associated stream was closed (ComplEventEnum or isEventStreamClosed = true).

    It is not fine to delete the omm client immediately.

    Please read the 6.4.1.5 Closing Event Stream section in the RFA developer guide.

Categories