This release provides the ability to specify XVM specific <env> properties in config DDL. For example:

<model>

<env>
  <property1>value1<property1>
  <property2>value2</property2>
</env>

<apps>
  <app name="app-1" mainClass="com.acme.MyApp">
  </app>
<apps>

<servers>
  <server name="xvm-1">
    <apps>
      <app name="app-1"/>
    <apps>
    <env>
       <property2>value2a</property2>
       <property3>value3a</property3>
    </env>
  <server>
</servers>

Would result in the XRruntime for server-1 ending up with:

• property1=value1
• property2=value2a (from xvm specific env)
• property3=value3a (from xvm specific env)

documentation is still in progress for the feature

This release introduces the ability to validate and enforce the value of a solace queue's max bind count when starting a solace message bus binding by setting

See Enforcing Max Queue Bind Count in the Talon Manual for more details

This release provides the ability for DDL config to define template apps, buses and xvms that can provide base configuration shared by multiple applications.

For example in the following DDL snippet tracing configuration is defined in the "app-template" which is referenced by the ems1 app which inherits that configuration.

<apps>
  <templates>
    <app name="app-template">
      <captureEventLatencyStats>false</captureEventLatencyStats>
      <captureTransactionLatencyStats>true</captureTransactionLatencyStats>
      <captureMessageTypeStats>true</captureMessageTypeStats>
      <capturePerTransactionStats>false</capturePerTransactionStats>
    </app>
  </templates>

  <app name="ems" mainClass="com.neeve.tick2trade.App" template="app-template">
    <messaging>
      <bus name="ems">
...

See DDL Config Reference for more details

documentation is still in progress for the feature

This release introduce DDL profiles as a new configuration feature. DDL profiles allow defining overlay configuration directly inside a the <profiles> section of a DDL. DDL profiles can be activated explicitly or via the profile's <activation> element which support the ability to automatically activate a profile based on environment variables.

<model>
  <apps>
    <app name="order-processor" mainClass="com.acme.MyApp">
      ...
    </app>
<apps>
<profiles>
  <profile name="troubleshooting">
    <apps>
      <app name="order-processor">
         <enableMessageTrace>true</enableMessageTrace>
      </app>
    </apps>
  </profile>
</profiles>
</model>

In the above code snippet if DDL is parsed with -Dnv.ddl.profiles=troubleshooting, the configuration defined in the troubleshooting profile will be overlaid on top of the main configuration.

See DDL Config Reference for more details.

documentation is still in progress for the feature

This release provides the ability to specify provisioning information in DDL Config. For example:

<xvm name="ems1">
  <provisioning>
    <host>192.168.1.13</host>
    <rootDirectory>/root/work/lumino</rootDirectory>
    <dataDirectory>rdat</dataDirectory>
    <qualifyPathsWithSystem>true</qualifyPathsWithSystem>
    <jvm>
      <javaHome>/usr/java/jdk1.8.0_60</javaHome>
      <jvmParams>
        -Xms8g
        -Xmx8
      </jvmParams>
    </jvm>
  </provisioning>
...

This allows provisioning tools such as Robin or Lumino to leverage configuration directly from DDL rather than relying on additional files such as <xvmname>.jvmparams or <xvmname>.env

For more information see DDL Config Refefence

documentation is still in progress for the feature

Prior to this release when DDL is specified in properties format (for users using an external configuration mechanism) unrecognized properties were ignored. With this release VMConfigurer now throws an error if any x.* property is specified that is not defined in the DDL xml schema.

Note that this validation does not apply to generic properties such as bus properties or env properties (that correspond to hierarchical properties in the DDL xml). Additionally this validation does not cover any properties that are outside of x.* configuration.
Compatibility Notes:

This release adds additional validation of DDL configuration supplied via properties rather than xml. Applications using properties based DDL configuration that pass in unknown x.* properties may fail to start. To revert to the old behavior of ignoring unknown properties, applications may set the property nv.ddl.propertynamevalidation=false in the ddl property set passed to VMConfigurer or as a system property.

This release provides DDL support for specifing <xvms> and <xvm> rather than <servers> and <servers>. The <servers> and <server> elements are deprecated, but remain usable for backwards compatibility ... with the caveat that only one or the other nomenclature can be used.
Compatibility Notes:

It is recommended that user's update their configuration DDL to switch from <servers> to <xvms> and from <server> to <xvm> as support the former variants will be dropped in a future release.

This release changes the ADM generated lendXXX(XString val) method to allow it to accept a null value without throwing a NullPointerException.
Compatibility Notes:

To take advantage of this change ADM models need to be regenerated. The ADM compatibility version was incremented from 3.8.0 to 3.8.1 as a result of this change.