Solace appliances now generate Threshold Crossing Alerts (TCAs) when ingress traffic to the Assured Delivery Blade (ADB) reaches specific thresholds. These thresholds are optionally configurable. The appliance clears the events when the traffic drops below the clear threshold.

Event brokers now automatically synchronize client certificates across High Availability (HA) pairs and Disaster Recovery (DR) replication sites, eliminating manual certificate file management. When enabled, client certificates configured for bridges, Kafka connectors, REST consumers, OAuth profiles, and DMR clusters are securely distributed to standby brokers in primary and replication sites without manual intervention. Configuration: Two independent control knobs: system level (OAuth, DMR and Replication) and message-VPN level (bridges, Kafka, REST consumers) enable -> configure -> config-sync -> synchronize -> client-certificate enable -> configure -> message-vpn -> config-sync -> synchronize -> client-certificate Default: Disabled for upgrades (opt-in), enabled for new installations Note: After enabling client certificate synchronization, you will need to run the assert-leader command to bring the system back into a synchronized state.

When using Kafka bridging, a Kafka Receiver returning to an operationally up state after previously been down may continuously disconnect and reconnect with the failure reason "AD publisher ack timeout". This may cause messages to be published to the bound queue more than once. Workaround: Delete and recreate the affected Kafka Receiver.

In High Availability (HA) appliance configurations, if all paths to external storage are lost simultaneously, the backup appliance may fail to activate due to filesystem corruption, resulting in both appliances being unable to access the message spool. This condition would typically happen during storage connectivity or failover testing, rather than in a stable production environment. Manual filesystem repair using the fsck Linux command is required to restore service.

When using Kafka bridging, a Kafka Sender may produce corrupted partition keys when the remote key substitution expression references user properties, causing incorrect message routing in downstream Kafka consumers while the sender remains operational.

Under high disk I/O load, a broker may become unable to process guaranteed messages, requiring a restart to recover. In High Availability (HA) configurations, this may cause redundancy to go down and fail to recover until the standby broker is restarted.

After an upgrade of a FIPS-image Software Event Broker, the broker will not start up successfully. This issue only affects the FIPS compliant image and not the standard Docker image.

In High Availability (HA) configurations with config-sync enabled, command logs on the HA mate broker may incorrectly attribute configuration changes to the wrong username when concurrent SEMP configuration requests are made by different users. This affects logging only, and the configuration changes are applied correctly.

For appliances only, publishing to and consuming from partitioned queues may significantly reduce message egress rates for other queues on the same event broker. Higher partition counts result in lower egress rates.

In rare cases, in High Availability (HA) deployments, the Active broker may advertise an incorrect Virtual Router Redundancy Protocol (VRRP) priority to its mate before completing its transition to Standby, allowing the mate to become active while the local broker is still transitioning, which can potentially lead to data corruption.

When the ‘show smrp subscriptions’ command is invoked via SEMP, it may exceed its configured timeout and run for extended periods when the broker has a large number of subscriptions and is experiencing frequent subscription changes. In extreme cases, this may cause the broker to restart.

The broker may restart when processing messages with metadata that is larger than approximately 1 MB through Kafka senders.

Large AMQP messages may fail to be delivered to the broker when the AMQP connection is configured with a maximum frame size that requires the message to be split into a large number of transfer frames.

Access tokens may be incorrectly encoded when forwarded to OAuth introspection endpoints, causing authentication to fail.

The software event broker can generate spurious I/O background processes, which can lead to performance degradation on the broker.

In High Availability (HA) deployments with software brokers, the Active broker may be unable to process messaging traffic if the Standby broker loses access to its underlying storage while maintaining network connectivity and remaining part of the redundancy group.
Workaround: Reboot the Standby broker.

Network instability affecting communication between brokers in a High Availability (HA) group may result in the broker failing to update its reported priority within the HA group and causing redundancy to be operationally down, as reported by the monitoring node.

Workaround: Execute `redundancy shutdown` followed by `no redundancy shutdown` on the affected broker.

REST Delivery Point (RDP) response timeouts and connection closures while awaiting an HTTP response now consistently count as delivery attempts toward a queue's max-redelivery limit. Customers with RDP consumers whose REST endpoints may experience timeouts or interruptions should review their queue's max redelivery and Dead Message Queue (DMQ) settings, as each such interruption now consumes a delivery attempt. For deployments using Distributed Tracing, the send-span outcome for RDP response timeouts and connection closures changes from 'released' to 'delivery-failed' or 'flow-unbound', where the close removes the RDP's last established connection.

The appliance may experience flash boot disk problems that appear to be hardware issues but are actually recoverable soft failures. A process to periodically check the health of the boot disk has been added and will raise a SYSTEM_CHASSIS_BOOT_DISK_FAIL event if a failure is detected. If you see this event, please contact Solace Support.

If the backup appliance in an active-active HA configuration is restarted while the message spool is disabled, re-enabling the message-spool will fail if one or more replay logs exist in the setup. This issue applies to Solace PubSub+ appliances only. Workaround: Set the active-standby redundancy role of the backup appliance to ‘backup’ prior to the restart. After the restart, set the active-standby role back to ‘none’.

The PubSub+ Software Event Broker needs larger TCP rmem/wmem settings to support multi-node routing neighbors across high RTT WAN links. Original bug: Bug 63008

SolOS will fail to start up if an invalid SSL certificate is configured via config-keys.

The PubSub+ Software Event Broker erroneously allows more user-created message-VPNs than are officially supported within the broker. This applies to all editions (Enterprise, Standard, and Evaluation). In a future release, this limit will be strictly enforced.