|Support for Kerberos client authentication|
Added Kerberos as a client authentication scheme.
|Additional Direct Receiver Back Pressure Strategies|
Added "drop latest" and "drop oldest" strategies to Direct Receiver Backpressure buffer. This gives more options for what to do with messages received when the message buffer fills.
|Replay after Replication Group Message ID|
Applications can now replay messages following the message-ID of the last message which they successfully-processed.
The feature uses "replication group message ID" which uniquely identifies messages within an HA group and Replication/DR group of brokers. The broker includes this ID in all guaranteed messages it delivers to the consumer. Consuming applications can extract and save this ID along with the message payload, and then use it later to initiate a replay.
This is a more "fine-grained" way to start a replay than from date-and-time, and is ideal in cases where the last message-ID successfully processed is known by the application (e.g. recovery from a database crash).
To initiate replay after message-ID from an application, both the PubSub+ Event Broker and PubSub+ Event API must be upgraded.
* PubSub+ Event Broker version 9.9.0
* PubSub+ Messaging API for Java version 10.11.0
* PubSub+ Messaging API for C version 7.18.0
* PubSub+ Messaging API for JavaRTO version 7.18.0
* PubSub+ Messaging API for .NET version 10.12.0
* PubSub+ Messaging API for Python version 1.2.0
Setting basic-username (via solace.messaging.authentication.scheme.basic.username) will no longer set the client username used for client-certificate authentication. Applications are now required to set client-certificate-username using solace.messaging.authentication.client-cert.username.
A large number of overlapping subscriptions in a single messaging service with a high rate of incoming matching messages from the broker may result in degraded performance.
Attempting to canonicalize very large messages on non-linux platforms (1MB+) via print or other means that invoke __str__() may not complete. When this occurs, the MessagingService will become unresponsive.
Messaging metrics within the Python API may be slightly out of sync (delayed) compared to the actual number of messages sent and received.
Attempting to disconnect the messaging service while it is in connecting state will cause the Python API to ungracefully shutdown.
RequestReplyMessagePublisher.terminate() waits until all Future created by RequestReplyMessagePublisher.publish() are complete. All Future created and returned by RequestReplyMessagePublisher.publish() must be completed before terminate() can finish. Even if terminate has a shorter or zero time, it will block until the outstanding futures are complete after the time has elapsed.
Application may choose to implement their own executor to call publish_await_response() for asynchronous publish. This will return a failure as expected on terminate.
The Class of Service feature is not supported in the Solace PubSub+ Messaging API for Python. This will be added in a future release.
After a service is disconnected, calling is_running(), is_terminating() or is_terminated() may return the incorrect state for the Publisher or Receiver.