OmmConsumer reissue problem

@mojtaba.danai

-Can you provide more details about what attributeInfo or payload you have modified?

-Is this possible to provide codes you are using so that we can try replicate it here?

-And can you please add <XmlTraceToFile value="1"/> to EMA Configuration. It will enable trace of request and response messages - default filename is 'EmaTrace'.

@moragodkrit

As mentioned the attributes we are trying to set on reissue call are "interestAfterRefresh(true)" and the "payload(viewElementList)", where viewElementList is an ElementList of filed ids that we are interested to receive and retrieve via UpdateMsg onUpdateMsg callback. The sample code as below:

ourConsumer.reissue (ReqMsg() .domainType(MMT_MARKET_PRICE) .serviceName(ourServiceName.c_str()) .name(ourSubscriptionCode.cstr()) .interestAfterRefresh(true) .payload(viewElementList) , ourhandle );

Where ourHandle is the output handle received from outrConsumer.registerClient call.

We also tried to only set the "interestAfterRefresh(true)" and the "payload(viewElementList)" attributes in the reissue call above, but the problem remains the same.

At the moment we have disabled the code which does the "reissue" call on our production environment so we can get the market data via Elektron. So I can not give you the trace file you have asked for unfortunately.

Also as mentioned earlier we do not have this issue on our test VPN connection to Reuters. And also all CME markets are affected.

Looking forward to know if whether there is problem with reissue call or not.

Thanks.

@mojtaba.danai

From my understanding you send streming reqeust with view to infra and wait until it receive some update and then call reissue to change view. If it's the case, reIssue should works and I don't think .interestAfterRefresh(true) will take any effect to the stream because the default value when you did not set is true(streaming).

I did a quick test with our example and not found issue with my test. Just modified Consumer360 from folder Examples to send streaming request in Main like this

UInt64 handle=consumer.registerClient( ReqMsg().serviceName( "API_ELEKTRON_EDGE_TOKYO" ).name( "AUD=" ).payload( ElementList().addUInt( ENAME_VIEW_TYPE, 1 ).addArray( ENAME_VIEW_DATA, OmmArray().fixedWidth( 2 ).addInt( 22 ).addInt( 25 ).complete() ).complete() ), client );

And then modify client to get handle with OmmConsumer object from Main thread and wait until it recieve around 5 update and call reissue to change view to add DisplayName filed using the following codes

pConsumer->reissue(ReqMsg().interestAfterRefresh(true).payload(ElementList().addUInt(ENAME_VIEW_TYPE, 1). addArray(ENAME_VIEW_DATA, OmmArray().fixedWidth(2).addInt(22).addInt(25).addInt(3).complete()).complete()), itemHandle);

I can receive a new refresh and get new field I just added and get udpate as usual.

Not sure that when you say "the whole application hangs in this call an does come out", Does it means you application has wait forever because it expect to recieve a new Refresh and Update, but it's not? Or it just freeze or hang after calling the method.

-Please turn on XML trace on the application that you can replicate the issue. We need to review what the application send and receive from infra at the time the problem occurs. You have to add <XmlTraceToFile value="1"/> to Channel config as described in

https://community.developers.thomsonreuters.com/questions/7929/view.html

The tracing log can help us check if item stream still open and receive data at the low level, or it does not receive anything back.

@moragodkrit

Thanks for the message.

What you did is almost what we have done at our end. When we make call to registerClient we make a send requestign request as below:

ourHandle = ourConsumer.registerClient
(ReqMsg()
.domainType(MMT_MARKET_PRICE)
.serviceName(m_serviceName.c_str())
.name(subscriptionCode.c_str())
.interestAfterRefresh(true)
, *this
);

As you can see at this point we do not set any view in our request. Later on when we receive the first refresh message, we read some other fields and then create our view element list of filed ids (as you have done) as:

ourConsumer.reissue(ReqMsg().domainType(MMT_MARKET_PRICE).serviceName(ourServiceName.c_str()).name(ourSubscriptionCode.cstr()).interestAfterRefresh(true).payload(viewElementList) , ourhandle );

The viewElementList is created as:

OmmArray filter;
filter.addInt(FieldId::TRDPRC_1)
.addInt(FieldId::TRDVOL_1)
.addInt(FieldId::ACVOL_1)
.addInt(FieldId::BID)
.addInt(FieldId::BIDSIZE)
.addInt(FieldId::ASK)
.addInt(FieldId::ASKSIZE);
someClassInstance->UpdateSearchList(filter);
filter.complete();
ElementList viewElementList;
viewElementList.addUInt(ENAME_VIEW_TYPE, 1).addArray(ENAME_VIEW_DATA, filter);
viewElementList.complete();

As said, strange thins is that we do not have this issue on our VPN test connection, but on our production server where we do NOT use VPN. Over the VPN connection the "reissue" method works fine!

And by hanging I mean, our data feed hangs when it gets into "reissue" call and does not come out of this call.

I will do some more tests tomorrow morning Sydney time when the markets are closed and enable tracing XmlTraceToFile as you suggested.

Hopefully we can get to the bottom of this issue.

Thanks.

@moragodkrit

I have created the attached trace file you requested by setting the XmlTraceToFile flag in EmaConfig file. I let the data feed run for 3 minutes and as mentioned it is never returned from "reissue" function call. The trace file size created is around 16 MB and it looks like the fieldList for the subscription code "ESU7" never finalised or completed (no matter how long I keep the program running)!

Also FYI, every time I stop and start the data feed, the trace file created stops randomly on an entry in the field list.

Hope this helps. Please let me know of your finding, and if it is possible escalate this issue further.

Thanks.

ematrace-13132646380886.zip

@mojtaba.danai

I have reviewed tracing log and found strange behaviour that tracing log stop since EMA writing some filed in FieldList of the first Refresh and it stop before EMA sending reissue to infra. I still unable to find reason why the applicaiton working fine after removed reissue logics. The request and information from login is so simple and it seems to be the same as my ADS server.

-What version of Elektron SDK you using (latest is 1.1.0 )?

-Have you tried to decode payload data from each field when you get first Refresh? and Does the application has some codes to handle the case that field contains blank value/unknown enum value?

-Do you have codes to handle exception when decode or process the Refresh? I understand that it's production environment but Is there anyway to attached the freeze process and save dump file?

-On both Production and VPN test environment. Are you using the same version of dictionary (RDMFieldDictionary and enumtype.def)? And are you testing with the same set of items? Perhaps comparing tracing log from both environment may help

I suspect that it might be the case that there are some exception occurs when application process the first Refresh and trying to send reissue. You are using EMA client in the same thread as application thread so it could causes the whole application freeze and EMA stop writing the log. My test example just print out the data to console so it does not have any error occurs.

@mojtaba.danai

Forgot to mentioned about your code which may causes exception. It's codes that you call

someClassInstance->UpdateSearchList(filter);

Have you called any methods from filter object in UpdateSearchList?

If you call some method for example, filter.getEntry, EMA should throws invalid usage exception because EMA does not support immediately retrieving data from freshly created OMM containers or messages.

@moragodkrit

We are using EMA 1.0.8

"filter" is just OmmArray and UpdateSearchList add couple of integers to the filter OmmArray and returns.

The code has exception handling and we can not see any exceptions. The data feed just hangs in the reissue call, and no exception is thrown!

We are using the same binaries both in Production and VPN environment including same libema.dll, libema.lib .... version.

If exception is happening while we are processing the first refresh message we should get an exception in our exception handler, which we don't. I checked the trace logs as well (nothing)!

We do not have enumtype.def in our binaries where data feed is running from. And in both environments (Production an Test) we are using ChannelDictionary as DictionaryType configured in EmaConfig.xml file.

Thanks

@mojtaba.danai

With regard to the difference between Production and VPN environment, is it possible that you collect the XML trace on both environment?

You can just run an EMA example such as 110_MarketPrice_FileConfig with XML trace enabled in both environments.

Also, I'm not sure if your application has enable the EMA log file. There might be some useful information in the log file once the reissue occurred. The configuration to enable EMA log file is below.

<LoggerGroup>
   <LoggerList>
     <Logger>
       <Name value="Logger_1"/>
    <!-- LoggerType is optional:  defaulted to "File" -->
    <!-- possible values: Stdout, File -->
       <LoggerType value="LoggerType::File"/>

@mojtaba.danai

Are you using API dispatch mode?

If yes, EMA thread will execute the onRefreshMsgcallback and call reissue.

However, if the application thread still calls OmmConsumer.registerClient() while EMA thread is in onRefreshMsgcallback, it could be a dead lock between the application thread and EMA thread.

The call stack of the EMA thread will look like:

The call stack of the application thread will look like:

Can the application behave in this scenario?