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
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:
- Properties that are not described as in the SolacBindingProperties 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.
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 Property | JCSMP Property | CCSMP 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 Property | nv.optimizefor=latency | nv.optimizefor=throughput | no optimization |
---|---|---|---|
"tcp_nodelay" | true | false | false |
"detached_sends_queue_wait_strategy" | See XRuntime.createWaitStrategy | See XRuntime.createWaitStrategy | Blocking |
"detached_dispatch_queue_wait_strategy" | See XRuntime.createWaitStrategy | See XRuntime.createWaitStrategy | Blocking |
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 |
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