The platform's solace binding includes both a java based and jni based implementation.

Bus Descriptor Format

A solace message bus can be configured via a descriptor string as follows:

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>
  </bus>
</buses>
<buses>
  <bus name="my-bus" descriptor=">
    <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>
  </bus>
</buses>

Solace Binding Specific 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 specific properties specified in the bus descriptor for the binding are passed through to the solace connection as follows:

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

Binding PropertyJCSMP PropertyCCSMP Property
"vpn_name""jcsmp.vpn_name""SESSION_VPN_NAME"
"username""jcsmp.usename""SESSION_USERNAME"
"password""jcsmp.password""SESSION_PASSWORD"
"publish_window_size""jcsmp.pub_ack_window_size""SESSION_PUB_WINDOW_SIZE"
"reconnect_retry_count""jcsmp.CLIENT_CHANNEL_PROPERTIES.ReconnectRetries""SESSION_RECONNECT_RETRIES"
"connect_retry_count""jcsmp.CLIENT_CHANNEL_PROPERTIES.ConnectRetries""SESSION_CONNECT_RETRIES"
"tcp_nodelay""jcsmp.CLIENT_CHANNEL_PROPERTIES.tcpNoDelay""SESSION_TCP_NODELAY"
"reapply_subscriptions""jcsmp.REAPPLY_SUBSCRIPTIONS""SESSION_REAPPLY_SUBSCRIPTIONS"
"ignore_subscriptions_error""jcsmp.IGNORE_DUPLICATE_SUBSCRIPTION_ERROR""SESSION_IGNORE_DUP_SUBSCRIPTION_ERROR"
MessageBusDescriptor.PROPNAME_ADDRESS
(the value from the bus descriptor address)
"jcsmp.HOST""SESSION_HOST"

Auto Tuning

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

Binding Propertynv.optimizefor=latencynv.optimizefor=throughputno optimization
"tcp_nodelay"truefalsefalse
"detached_sends_queue_wait_strategy"See XRuntime.createWaitStrategySee XRuntime.createWaitStrategyBlocking
"detached_dispatch_queue_wait_strategy"See XRuntime.createWaitStrategySee XRuntime.createWaitStrategyBlocking

 

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.

When the Solace appliance and binding is configured with SEMP over messaging enabled the binding can request a list of the subscriptions on the queue and compare them with those issue by the binding. 

Orphan Subscription Check Policies

The following policy can be configured to check for orphan subscriptions

 Policy Desecription
None

With this policy, the appliance is not queried for subscriptions

This is the default policy

Ignore

With this policy enabled the appliance is queried for subscriptions, but no action is taken other than tracing the orphans subscriptions at info level.

One other difference between SolaceOrphanSubscriptionCheckPolicy.None and SolaceOrphanSubscriptionCheckPolicy.Ignore is the the query subscriptions are reported to a subscription validator if registered. 

LogExceptionAndContinue

With this policy enabled the appliance is queried for subscriptions and if orphands are found an exception is logged.

NoOrphan

With this policy enabled the appliance is queried for subscriptions and an exception is thrown from the message binding start method.

Configuration