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.

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.

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’.

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

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

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.