Consumer application crashed in RFA_String::set() when processing a refresh message

My consumer application bases on Consumer example in RFA package. Last week, it crashed with the following call stack.
rfa::common::RFA_String::set(char const*, unsigned int, bool) ()
rfa::common::RFA_String::RFA_String(rfa::common::RFA_String const&, rfa::common::RFA_String const&) ()
rfa::common::operator+(rfa::common::RFA_String const&, rfa::common::RFA_String const&) ()
MarketPriceClient::displayServiceAndItemName (this=…, respMsg=..., cacheItem=..., temp=...)
MarketPriceClient::processRefreshRespMsg (this=…, respMsg=..., cacheItem=..., temp=...)
MarketPriceClient::processEvent (this=…, event=...) rfa::common::EventQueueImpl::dispatch(long)
From the code, it crashed at this line.
void MarketPriceClient::displayServiceAndItemName( const RespMsg& respMsg, ConsumerItem& cacheItem, RFA_String& temp )
{
...
temp += cacheItem.getName() + RFA_String( " :\n", 0, false );
}
It seems that cacheItem is invalid. The application log before crash was:
11:32:30
RDMConsumerClient : Status Msg : ELEKTRON_EDGE – TRI.N :
Status :
DataState : Suspect
StreamState : Open
StatusCode : None
StatusText : Item is stale
11:33:40
RDMConsumerClient: Received Final Stream State : 'Closed' for MarketPrice item: 'TRI.N'
RDMConsumerClient : Status Msg : ELEKTRON_EDGE - TRI.N:
However, another instance of the application running on a different machine didn’t crash. Both applications connected to the same server. The log of this application at that time was:
11:32:30
RDMConsumerClient : Status Msg : ELEKTRON_EDGE - TRI.N :
Status :
DataState : Suspect
StreamState : Open
StatusCode : None
StatusText : Item is stale
11:33:40
RDMConsumerClient : Status Msg : ELEKTRON_EDGE - TRI.N:
11:55:35
RDMConsumerClient: Received Final Stream State : 'Closed' for MarketPrice item: 'TRI.N'
RDMConsumerClient : Status Msg : ELEKTRON_EDGE - TRI.N:
Status :
DataState : Suspect
StreamState : Closed
StatusCode : None
StatusText : Record dropped from network
Please let me know the cause of this issue and how to fix this problem.
Best Answer
-
From the application log, at 11:33:40, both applications
received the status message of TRI.N. The crash application logged this status
message as CLOSED stream state while the non-crash application logged it as the
status message without response status information (stream state, data status,
and status, and status text).I assume that
at 11:33:40, the applications received the status message without RespStatus
information from the server, as shown below.<statusMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="5" containerType="RSSL_DT_NO_DATA" flags="0x0" dataSize="0">
<dataBody>
</dataBody>
</statusMsg>According to RDM usage guide, RespStatus is optional.
Therefore, the above status message is valid.I have verified the Consumer example code in RFA package and
found that the code is unable to handle this status message (without
RespStatus).At line 146-147, the code verifies the presence of
RespStatus before displaying it. However, the code at line 154 – 159 doesn’t
verify the presence of RespStatus before using it. The application will get the
invalid or outdated RespStatus which causes the application behaves
unexpectedly.For the problem, I assume that the crash application
retrieved the CLOSED stream state from the outdated RespStatus and then it
closed the stream and destroyed the closure. After that, the application
received and processed the refresh message of the TRI.N sent by the server, and
then it crashed when accessing the destroyed closure.To handle this scenario, the application must be modified to
verify the presence of RespStatus before using it.// Check for final stream states viz. 'Closed', ClosedRecover etc.
// These states are usually reported in status messages.
if (respMsg.getHintMask() & RespMsg::RespStatusFlag){
const RespStatus &respSt = respMsg.getRespStatus();
const RespStatus::StreamState strState = respSt.getStreamState();
if (strState == RespStatus::ClosedEnum ||
strState == RespStatus::ClosedRecoverEnum)
{
...Please verify the application code to make sure that it has verified the presence of RespStatus before accessing it. Hope this help.
0
Answers
-
Thank you. I will modify the code to handle this message.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 24 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 279 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 713 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛