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
If I were to change the ChannelSet specification to this:
<ChannelSet value="Channel_1, Channel_2"/>
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:
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.
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.
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.