JNI vs JAVA Binding

The Java binding uses solace's JCSMP api while the JNI binding uses solace's CCSMP api. The JNI binding supports zero garbage messaging while in steady state, but only works on linux platforms. The Java binding is not zero garbage but works on all platform supported by X. Other differences between the two bindings are:

• UnhandledMesssageEvents issued by the JNI binding return the subscription name rather than the sent topic name.
• UnhandledMesssageEvents issued by the JNI binding return a session specific sequence number rather than the appliance wide sequence number in the transport specific message id. 
• The provider properties passed through to the underlying property differ depending on the underlying solace library used. The binding rationalizes some of the common properties between the two implementations. See the configuration section below for more details. 

Bus Descriptor Format

A solace message bus can be configured via a descriptor string as follows which takes the connection information followed by a list of provider properties. 

solace://<address>:<port>&prop1=val1&propN=valN

An example bus descriptor for solace would like like:

solace://<address>:<port>&usejni=true&vpn_name=default&username=test& /
password=test&usejni=true&vpn_name=default&username=test&password=test

DDL

In a DDL config file a solace bus can equivalently be configured in one two ways

<buses>
  <bus name="my-bus">
    <provider>solace</provider>
    <address>192.168.1.9</address>
    <port>55555</port>
    <properties>
      <usejni>true</usejni>
      <vpn_name>default</vpn_name>
      <username>test</username>
      <password>test</password>
    </properties>
    <channels>
      ...
    </channels>
  </bus>
</buses>

<buses>
  <bus name="my-bus" descriptor="solace://<address>:<port>&amp;usejni=true&amp;vpn_name=default&amp; /
   username=test&amp;password=test&amp;usejni=true&amp;vpn_name=default&amp;username=test&amp;password=test">
    <channels>
      ...
    </channels>
  </bus>
</buses>

The descriptor form is useful in cases where the descriptor name may be supplied as an external configuration property that is substituted for example:

<buses>
  <bus name="my-bus" descriptor="${myBusDescriptor::loopback://mybus">
    <channels>
      ...
    </channels>
  </bus>
</buses>

Solace Provider Properties

Passed Through Properties

The solace JCSMP and JNI apis on which the platform's solace binding is built allow configuration of the connection by specifying properties. The provider properties specified in the bus descriptor for the binding are passed through to the solace connection as follows:

• Properties that are not described as in the SolaceBindingProperties javadoc are stripped out. 

• General Bus properties defined in MessageBusDescriptor javadoc are also stripped out.

• Properties listed as 'Rationalized Properties' below are translated according to whether the jni or java binding implementation will be used these.
• If "usejni" is true, then any remaining properties that don't start with "FLOW_" or "SESSION_" are are stripped, the rest are passed through opaquely.
• If "usejni" is false, then any remaining properties that don't start with "jcsmp" are are stripped, the rest are passed through opaquely.

See the solace documentation for more information on JCSMP and CCSMP. Neeve, does not test properties not explicitly called out on this page or in the javadoc. End users should therefore do their own due diligence in testing any passed through properties. 

Rationalized Properties

To make is easier for applications to switch between using the jni (c) and jcsmp (java) binding implementations, several commonly used binding properties are automatically translated by the binding. These are summarized in the table below. If your application doesn't use any additional solace configuration properties then switching between the java a c

Additional Properties

See the SolaceBindingProperties javadoc for the listing of additional provider properties specific to the solace binding.

Auto Tuning

When not explicitly as binding property, the following properties are automatically set on the binding based on the global optimization value.

Orphan Subscription Checks

When a solace message bus binding has a queue name specified it is capable of issue guaranteed subscriptions against that queue. When a binding is started it is possible that there may already be existing subscriptions on the queue that don't match those that the application is issuing. Such subscriptions are considered to be 'orphan' subscriptions - presumably those left over from an early session that were not removed.

The following policy can be configured to check for orphan subscriptions

Configuration

To check for existing subscription SEMP must be enabled for the binding to retrieve the list of subscriptions over the messaging connection. The following provider properties must be specified on the bus descriptor to perform subscription checks: