Release Notes: Solace PubSub+ Messaging API for Java (JCSMP), Version 10.16.0
Release History for Solace PubSub+ Messaging API for Java (JCSMP), Version 10.16.0
September 2022

New Features Introduced in Release 10.16.0 and Earlier Releases

This section lists the new features introduced in the Solace PubSub+ Messaging API for Java (JCSMP) between releases 10.16.0 and 10.10.0.
NameDescriptionIntroduced in Version
JCSMP - Add Way to Update Oauth Token on Reconnection
This feature allows an application to automatically update the OAuth token, without the need to create a new session, the next time the API tries to reconnect.
API Server Certificate Validation Using Subject Alternate Name
This feature will compare the DNS name that the API is trying to connect to to the DNS name stored in the subject alternate name of the server certificate, following the current security best practice for TLS connections.
Prevent Republishing of Guaranteed Messages that Exceed the Maximum Message Size
This feature will prevent applications from sending guaranteed messages that exceed the maximum message size configured in the PubSub+ Event Broker to prevent erroneous states in the API.
Allow Client Cert and Trust Store to be Passed as Object
Trust store and key store can now be passed to the API as a Java trust store object. This allows for the configuration of SSL connections without the need of pointing to an SSL-trusted store file on the local file system.
Remove Use of Out of Date Apache Commons Libraries
Removed usage of and dependencies on various Apache Commons libraries including commons-lang and commons-collections.
OAuth/OIDC Support in Messaging API for JCSMP/JMS
OAuth / OpenID Connect has been added as a method of authenticating and authorizing clients connecting to the PubSub+ Event Broker using the SMF protocol. Clients using Solace APIs will be able to present a token as a credential during client login. This enables clients to integrate with modern identity and access management systems.
Increase the Maximum Number Of Messages in a Transaction
This feature increases the transaction scaling limits to allow up to 20,000 messages (consume plus publish) in a single transaction. The previous limit was 256 messages. To use this feature, you must upgrade your PubSub+ Event Brokers to Release 9.8.1 or later.
This feature is a Controlled Availability feature. Solace recommends that before you enable this feature on your event broker, contact Solace to review your use case. Solace will work with you to verify that the feature is suitable for production use in your environment.
JCSMP/JMS Support for SNI
The JCSMP API and its derivatives (JMS) will now populate the SNI field when negotiating a TLS connection.
End of Life Support for Java 6 and Java 7
Solace is deprecating support for Java versions 1.6 and 1.7 with the intention that future releases of the Java API (JCSMP) will NOT be supported on Java versions prior to 1.8. Java versions prior to 1.8 are not supported by Oracle or OpenJDK, making it impossible for Solace to maintain support for older versions of the language.
Release 10.10 will be the last Solace Java API version that supports versions prior to Java 1.8.

Issues Resolved in Release 10.16.0 and Earlier Releases

This section lists the history of resolved issues in the Solace PubSub+ Messaging API for Java (JCSMP) between releases 10.16.0 and 10.10.0.
Reference NumberDescriptionResolved in Version
In rare cases, the messaging API may deadlock while automatically re-transmitting guaranteed messages due to a timeout waiting for an acknowledgement from the broker. Note this is a different deadlock compared to what was reported and fixed in SOL-59955.
If the application disconnects and reconnects while in the process of creating a new producer it may get a "400: Too Many Publishers" exception. This error is expected to occur very rarely.
If an application thread is interrupted while waiting for a response from the broker to a request to create a consumer for a queue or durable topic subscription, and the API is in the process of reconnecting, the application thread and an API thread may deadlock. This issue can only occur if using JMS 10.11.0 or later with broker 9.8.1 or later.
The API's keepalive mechanism has been improved to avoid false positive keepalive failures while receiving large messages over slow networks.
Interrupting an application thread while it is calling commit() or rollback() for a transacted session may cause the transacted session object to be unusable, and subsequent calls to the object's commit() or rollback() methods will throw an exception. This issue can only occur if using at least version 10.11 of either the JCSMP or JMS API with a broker running at least version 9.8.1 of SolOS. Earlier versions of either the API or broker are not exposed to this issue.
Starting in JMS and JMCSP 10.13.0, client applications that directly or indirectly use apache-commons-lang v2 library classes ArrayUtils or SystemUtils could trigger a NoSuchMethodError at runtime.
This issue only exists in version 10.13.0. Users of that version can avoid the issue either by upgrading to version 10.13.1 or by applying one of the following workarounds. Implementing either one will avoid this problem. (1) Upgrade client applications to use apache-commons-lang v3 (apache-commons-lang v3 superseded v2 in 2011). (2) Ensure that the classpath variable includes apache-commons-lang before including Solace libraries.
XA transactions may be rolled back if a consumer used to receive messages as part of the transaction is closed before committing the transaction.
The messaging API may deadlock while automatically re-transmitting guaranteed messages due to a timeout waiting for an acknowledgement from the broker.
The Java/JMS API can deadlock when the internal reactor thread is blocked on trying to send a message.
As an example, this can occur when the TCP socket's send buffer is full and the application attempts to unbind from an endpoint.
Messages received by the API should be read-only but this is not the case for messages received over a shared subscription.
If the API receives a corrupted message such that the decoded length of the binary metadata portion greatly exceeds the length of the byte buffer, the API may not reconnect to the broker as it is supposed to.
If the API is in the process of retransmitting guaranteed messages and is also reconnecting to the broker but fails to reconnect within the configured number of retry attempts, the thread used to retransmit the guaranteed messages is not shut down as expected. The only impact is that the thread will use a small amount of CPU resources until the application exits or shuts down the context used to create the original connection.
TransactedSession.createProducer(ProducerFlowProperties fprop, ...) fails to respect the window size specified in the ProducerFlowProperties. Instead, the value for previous versions was always set to 255.
Solace recommends against using either JCSMP 10.11.0 or JMS 10.11.0 with SolOS due to broker issue SOL-47779: AdCtrl v4 publishers can stall due to lost acks which exists only in SolOS There is no issue using these versions of the APIs with earlier or later versions than of SolOS.
The JCSMP and JMS APIs may always return a delivery count of 1 for messages consumed or browsed from a queue or topic endpoint with the delivery count feature enabled. This issue only occurs with versions 10.10.0 and 10.10.1 of the JCSMP and JMS APIs and only with broker versions or later. If using a 9.8 version of the broker the issue can only occur if the message is consumed as part of an XA transaction. If using a 9.9 or later version of the broker the issue can occur regardless of how the message is consumed or browsed.
When the API is integrated with Camel and Spring, if a disconnection occurs and the API fails to reconnect to the broker within the configured number of reconnect attempts, a deadlock between the API and Spring, Camel, or the application threads may occur. This will prevent the application from being shut down without restarting the JVM.

Changed Functionality in Release 10.16.0 and Earlier Releases

This section lists the history of changed functionality in the Solace PubSub+ Messaging API for Java (JCSMP) between releases 10.16.0 and 10.10.0.
Reference NumberDescriptionIntroduced in Version
To accommodate environments in which access to the default Java trust store jssecacerts is restricted, the API now only checks for the default Java trust store, if using SSL and no other trust store is specified. If there is an exception accessing the default trust store the API now handles it.
Apache commons logging has been upgraded from 1.1.3 to 1.2.
The class names responsible for raising transaction-related log entries may change after upgrading the Solace Broker and API.
The format of reply-to topics has changed. The reply-to topic used by the API's request/reply helper methods used to be of the form:
The trailing # has been replaced with an underscore _ such that the topic is now of the form:
In JCSMP, the suffix of a reply-to topic set with the setReplyToSuffix() method is also now prefixed with the underscore("_") character.

Known Issues in Release 10.16.0 and Earlier Releases

This section describes known issues in the Solace PubSub+ Messaging API for Java (JCSMP) between releases 10.16.0 and 10.10.0.
Reference NumberDescription
The JCSMP/JMS API may lock up if an application thread continuously interrupts JCSMPXMLMessageProducer.send() and triggers a session reconnect.
For more details, refer to the Release Notes page for the individual Solace Messaging APIs.

Supported Environments