EMA C++ uses unexpected XmlTrace parameters in EmaConfig.xml configuration file

Consider the following EmaConfig.xml contents:

<?xml version="1.0" encoding="UTF-8"?>
<EmaConfig>
  <ConsumerGroup>
	  <DefaultConsumer value="Consumer_1"/>
	  <ConsumerList>
		  <Consumer>
			  <Name value="Consumer_1"/>
			  <ChannelSet value="Channel_1"/>
		  </Consumer>
	  </ConsumerList>
  </ConsumerGroup>

  <ChannelGroup>
	  <ChannelList>
		  <Channel>
			  <Name value="Channel_1"/>
			  <ChannelType value="ChannelType::RSSL_SOCKET"/>
			  <CompressionType value="CompressionType::None"/>
			  <TcpNodelay value="1"/>
			  <Host value="elektron"/>
			  <Port value="14002"/>
     		  <XmlTraceToFile value="1"/>
			  <XmlTraceFileName value="AdminMsgs1"/>
		  </Channel>

		  <Channel>
			  <Name value="Channel_2"/>
			  <ChannelType value="ChannelType::RSSL_SOCKET"/>
			  <CompressionType value="CompressionType::None"/>
			  <Host value="bad IP"/>
			  <Port value="14002"/>
			  <XmlTraceToFile value="1"/>
			  <XmlTraceFileName value="AdminMsgs2"/>
		  </Channel>
	  </ChannelList>
  </ChannelGroup>
</EmaConfig>

In the above, the consumer stanza is instructed to specifically use the "Channel_1" channel to define the connection specifications for the application. In this situation, everything works perfectly. The application connects as expected and the XmlTraceToFile is created with a syntax of

AdminMsg1.<process #>.xml.

If I were to change the ChannelSet specification to this:

<ChannelSet value="Channel_1, Channel_2"/>

Things change.

I still successfully connect into Channel_1 as before, however, the XmlTrace is using the one defined within Channel_2 ! That is, I now get an XmlTraceToFile created with a syntax of:

AdminMsg2.<process #>.xml.

For some reason, it's taking the specification from Channel_2 despite successfully connecting into the specification defined within Channel_1.

I'm guessing this is likely an issue within EMA.

Find more posts tagged with

c++

configuration

xml

elektron

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

Accepted answers

brian.sandri

@Rupert Schilling

The team is analyzing the way this is configured today and working out a manner to make it more intuitive in the case of ChannelSet use. Thank you for providing your feedback, we are taking action as a result.

Some of the behaviors that are implied from the current method of configuration are not possible in underlying layers - for instance, having a different config file name per channel in the channel set is not able to be configured in the lower transport layers as it exposes a single config instance with a list of host:port combinations. As a result, common parameters like xml tracing, recovery times, etc are set up once and enforced consistently across channels in the ChannelSet.

We will likely pull the common config parameters up to be configured on the ChannelSet or the Consumer config hive so they are set once as opposed to the 'last channel configured wins' approach. We feel this would make the behavior more logical and help indicate that these are set once across connections in the ChannelSet as the underlying behavior truly enforces.

Hope this will help.

Brian

All comments

may.du

This is expected behavior. Please take a look at EMA configuration guide.

3.3.7Example Programmatic Configuration for ChannelSet

The following is an example programmatic ChannelSet configuration. In this example, the consumer uses the Channel parameters ReconnectAttemptLimit, ReconnectMinDelay, ReconnectMaxDelay, XmlTraceFileName, XmlTraceMaxFileSize, XmlTraceToFile, XmlTraceToStdout, XmlTraceToMultipleFiles, XmlTraceWrite, XmlTraceRead and MsgKeyInUpdates of the last channel. Though each channel in the ChannelSet can have different values for these parameters, EMA uses parameter values as set for the last channel in the set (even if the consumer successfully connects to a different channel in the ChannelSet).

This defined behavior also applies configuration setting read from EmaConfig.xml file.

LtDoolittle6

If this is expected behavior, there must be some really good reason as to why because frankly, this is nonsense.

Logically, when you define a configuration for a specific Channel stanza, you would expect all properties within that configuration would be applied, not just a select few. What is the point of allowing the user to define them when they can't be used? Then further confuse them when parameters from other stanza's are being applied.

Simple question: I have 2 channels defined and simply want to define unique properties for each, eg the name of my trace file.

How do I do it?

brian.sandri

@Rupert Schilling

Hope this will help.

Brian

LtDoolittle6

Thanks Brian. I think the important element, which you identified, is that the configuration needs to be at the parent level. This will obviously make sense and avoid confusion and frustration for the developer.

EXPLORE OUR SITES