EMA Issue with update items

yajnasteju

Hello,

We are currently facing an issue with EMS service , where in , we received the refresh messages properly for all subscribed items , but , post that , update messages were not received by the application.

at 11:12 : We stopped receiving update items.

We had raised the issue with TR support and they had checked ADS logs with the below findings,

11:19 : Warning Output threshold breached for EMS_ID at position X.x.x.x on host abc using application on channel xx.

11:20 : RSSL disconnect from "EMS_ID" at position "x.x.x.x" on host "abc" using application "" on channel xx. Reason: User using application on channel xx has been disconnected due to an overflow condition.

But during all these , the EMA log had no events logged , We have earlier observed that , if there is any disconnection , the event is logged in EMA log and re-connection happens internally by EMA Cpp library.

During all the time , we checked the connection to RSSL port 14002 and the connection was in ESTABLISHED state only .

Kindly help resolve this .

Jirapongse

@yajnasteju

When the connection has been disconnected, EMA will recover the connection and item requests on behalf of the application. Moreover, the EMA log will report the channel down message, as shown below.

loggerMsg
    TimeStamp: 09:54:04.387
    ClientName: ChannelCallbackClient
    Severity: Warning
    Text:    Received ChannelDownReconnecting event on channel Channel_1
	Instance Name Consumer_1_1
	RsslReactor 0x00000000005EA050
	RsslChannel 0x00000000005EA050
	Error Id -1
	Internal sysError 10054
	Error Location ..\..\..\ValueAdd\Reactor\Impl\rsslReactor.c:3140
	Error Text <..\..\..\Ripc\Impl\ripcsrvr.c:6820> Error:1002 ripcRead() failure. System errno: (10054)
loggerMsgEnd


loggerMsg
    TimeStamp: 09:54:04.387
    ClientName: LoginCallbackClient
    Severity: Warning
    Text:    RDMLogin stream state was changed to suspect with status message
	username user
	usernameType 1
	position 127.0.0.1/net
	appId 256
	applicationName ADS
	instanceId <not set>
	singleOpen 1
	allowSuspect 1
	optimizedPauseResume 1
	permissionExpressions 1
	permissionProfile 0
	supportBatchRequest 1
	supportEnhancedSymbolList 1
	supportPost 1
	supportViewRequest 1
	role 0
	State: Open / Suspect / None / 'Channel is down.'
loggerMsgEnd

The severity level of the channel down log is LoggerSeverity::Warning (2). Therefore, to get the channel down log, the LoggerSeverity configuration of the channel must be LoggerSeverity::Verbose (0), LoggerSeverity::Success (1), or LoggerSeverity::Warning (2).

<Logger>
	<Name value="Logger_1"/>
	<!-- LoggerType is optional:  defaulted to "File" -->
	<!-- possible values: Stdout, File -->
	<LoggerType value="LoggerType::File"/>
	<!-- LoggerSeverity is optional: defaulted to "Success"	-->
	<!-- possible values: Verbose, Success, Warning, Error, NoLogMsg-->
	<LoggerSeverity value="LoggerSeverity::Success"/>
</Logger>

yajnasteju

As mentioned in the question itself , None of the events were logged in EMA log.

Below is the logger config;

<Logger>

<Name value="Logger_1"/>

<LoggerType value="LoggerType::File"/>

<FileName value="reuters"/> <LoggerSeverityvalue="LoggerSeverity::Success"/> <IncludeDateInLoggerOutput value="1" />

</Logger>

We have earlier observed these channel down and reconnect logs , but during this particular issue , no such events were recorded.

Jirapongse

@yajnasteju

Could please share the TREP log and EMA log when the problem occurred?

yajnasteju

There is nothing logged in EMA log during the issue. The last log written was on Successful Login .

loggerMsg TimeStamp: 2017/05/25 07:15:01.392 ClientName: ChannelCallbackClient Severity: Success Text: Received ChannelUp event on channel TR_TestVPN_Channel1 Instance Name Consumer_1_1 Connected component version: ads2.6.11.L1.linux.tis.rrg 64-bit loggerMsgEnd

Jirapongse

Could you please set XmlTraceToFile to 1 under the Consumer configuration?

...   
  <XmlTraceToFile value="1"/>
</Consumer>

This configuration will create a EmaTrace_xxx.xml file. We need to see messages retrieved by EMA.

Nipat Kunvutipongsak

Hello @yajnasteju,

I'm wondering whether this problem still persists or not. If no, can you obtain the additional evidences (e.g. Ema Trace file as suggested by Jirapongse) for this problem? It'll be helpful to identify the culprit of the problem.