DMR Export Filters can now be configured on gateway nodes in a DMR network. The Export Filters apply to the subscriptions that are advertised to other clusters over an external link. The filters are in the form of lists of subscriptions supporting wildcards (* and >) and negative subscriptions (prefixed with !). A subscription is exported if there are no positive entries in the filter list, OR at least one positive entry matches it AND, no negative entry matches it.

Solace event brokers now log Advanced Message Queuing Protocol (AMQP) session and link events. AMQP debugging shows human-readable Message VPN and client names for each AMQP session and link. This debugging information is available in the CLI, so you can diagnose AMQP session and link flow-control problems without shell access or packet capture.

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 can now automatically synchronize client certificates across high-availability pairs and disaster recovery replication sites, eliminating the need to manually copy certificate files to standby nodes.
Synchronization is controlled independently at two scopes:

Global scope—synchronizes certificates for OAuth profiles, DMR cluster links, and replication bridges.
Message VPN scope—synchronizes certificates for Message VPN bridges, REST consumers, and Kafka senders and receivers.

By default, both scopes are disabled after an upgrade and enabled on new installations.

During an upgrade, messages on the Disaster Recovery (DR) standby site may be incorrectly removed when acknowledgments are propagated from the DR active site. Affected messages may be removed from the DR standby site while remaining present on the DR active site.

When upgrading from releases 10.26.2-10.26.6 to 10.26.7 or later, the broker fails to start and restarts repeatedly if a syslog configuration uses the “audit” or “metric” facility.

The broker's standard domain certificate authority list, which is enabled by default, includes root certificates (emSign ECC Root CA - G3, emSign Root CA - C1, and emSign ECC Root CA - C3) that are no longer trusted ( https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 ). A broker that makes outbound TLS connections, for example to REST consumers or OAuth providers, would accept a server certificate chaining to one of these roots.

An external Dynamic Message Routing (DMR) link may remain down with a reason of "Unknown Queue" when the remote node has a separate, unrelated external link with synchronization failures. The condition clears automatically once the unrelated link on the remote node is repaired or shut down.

On software brokers only, if the High Availability (HA) mate link connection repeatedly disconnects and reconnects over a sustained period, the HA pair may be unable to re-establish the connection.

When the legacy TLS 1.2 and below cipher suite list is empty, the broker refuses incoming connections even when TLS 1.3 could be used.

When a REST or TLS client resets its connection while waiting for login, the broker may not detect the reset and continue to hold the connection open for up to 30 seconds. Under a login backlog, these stale connections can accumulate and count against the SSL connection limit.

During broker startup, a race condition may cause incorrect processing of replication bridge updates, potentially leading to messages being incorrectly acknowledged on the Disaster Recovery (DR) standby site.

When an AMQP client rejects a message using the 'rejected' outcome, the broker may attempt redelivery instead of moving the message directly to the Dead Message Queue (DMQ).

On software brokers only, a high rate of concurrent client certificate authentications may exhaust the broker's resources, resulting in degraded performance and, in severe cases, a broker restart.

When enabling Dynamic Message Routing (DMR), or when Export Subscriptions is enabled for a Multi-Node Routing (MNR) network, a broker may not properly export some subscriptions to remote brokers .

Workaround: For MNR, disable and re-enable Export Subscriptions on the affected Message VPN. For DMR, shut down and re-enable Dynamic Message Routing on the affected Message VPN. Before re-enabling, verify that the Message VPN has completed its subscription export by confirming that Export Subscriptions reports as fully complete.

For appliances only, on systems with a Network Acceleration Blade (NAB) model NAB-0810EM-01-A or NAB-0410EM-01-A, large bursts of network traffic, including ICMP and ARP, may delay Link Aggregation Control Protocol (LACP) timer processing, causing the switch to detect LACP timeouts. This can result in all ports detaching from their Link Aggregation Groups (LAGs) and potentially triggering a failover.

When an AMQP client publishes guaranteed messages and the broker fails to deliver the message to its destination, the broker sends a 'rejected' disposition instead of the more appropriate 'modified' disposition with 'delivery-failed' set to true.

The broker may restart when sending a large batch of AMQP acknowledgment messages to publishers over TLS connections. This can occur during high-throughput publishing scenarios where a large number of messages are acknowledged simultaneously.

Configuration backups from brokers configured for High Availability (HA) cannot be restored to a different broker instance. This issue affects all backups created on versions 10.25.13.4187 to 10.25.24.8245, 10.26.0.8586 to 10.26.0.9000, and 10.26.1.9198 to 10.26.7.12655. If you encounter this issue when restoring a backup, contact Solace support for assistance.

The broker may restart when it receives a message containing a transaction ID that does not belong to any active transacted session.

The broker may restart due to a race condition when generating diagnostic information about stalled flows on partitioned queues if those flows have been recently disconnected.

The broker may restart when configuring a Kafka sender with a name containing multi-byte UTF-8 characters, which can cause repeated broker restarts until the configuration is corrected.

For appliances only, the broker may disconnect slow subscribers without raising a SYSTEM_NAB_BUFFER_LOAD_FACTOR_HIGH event when the Network Acceleration Blade (NAB) enters congestion due to high buffer usage.

On appliances only, Dynamic Message Routing (DMR) cluster links fail with "MsgBackbone Static IP Interface Disabled" when the message backbone static IP address is left unchanged but the interface is administratively shut down and re-enabled.

When accessed through a cookie-based pre-authenticating reverse proxy, the Broker Manager may display "No authentication methods are currently enabled for Broker Manager" and fail to load. Note that reverse proxies and web application firewalls must now be configured to allow the new GET /authMethods endpoint.

For appliances only, in the rare event of an out-of-memory (OOM) condition, the broker may remain stopped and not restart automatically.

When partitioned queue consumers fall out of streaming mode, the broker may experience reduced message egress rates on other queues.

The Event Broker does not capture full debug information in some rare unexpected NAB restart circumstances.

The broker may restart when publishing messages to topics matching the subscriptions of at least one guaranteed endpoint, and at least two conditional delivery endpoints, at least one of which must also have a matching subscription exception. Conditional delivery endpoints include replication, telemetry and the replay log.

For appliances only, during a software downgrade the Java runtime directory may be incorrectly pointed to a non-existent path, preventing the SolGeneos monitoring service from accessing its Java runtime environment. Workaround: Run “ln -sfn /etc/alternatives/jre1.8.0openjdk /usr/sw/java” as root user, or perform a subsequent upgrade which will automatically correct the directory path.

Persistent messages sent within a transacted session, forwarded over a guaranteed bridge and then a direct bridge, may become stuck and cannot be consumed or deleted when they are promoted at the destination endpoint.

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.

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

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.

The broker may restart when processing malformed data during OAuth/JWT authentication.

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.

Legacy SEMP (SEMPv1) replies that show client username details or statistics now correctly nest each “client-username-attribute” element inside the “client-username-attributes” element, as defined in the SEMPv1 reply schema.

On FIPS-enabled brokers, the ‘ssl server-certificate’ command no longer rejects certificates signed with MD5 or SHA-1. Ensure server certificates use FIPS-approved signature algorithms.

MQTT clients connecting with Clean Start = 0 are now refused when an orphaned queue exists for the client ID. The event broker refuses the connection with a CONNACK of “Not Authorized” with a a return code 5 for MQTT 3.1.1 or a reason code 0x87 for MQTT 5 and logs the reason as "MQTT Orphaned Queue Present" in the event log. Previously the event broker allowed the connection, attached the orphaned queue, and incorrectly reported Session Present = 0.

To recover, reconnect with Clean Start = 1. Reconnecting with Clean Start = 1 deletes the orphaned queue and the messages in it. Alternatively, a person with the administrator role can create the MQTT session, which adopts the queue and keeps the messages. The administrator can also create the session and then delete it, which clears the queue without the client reconnecting.

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

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.

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