Skip to content

TBMQ 1.3.0 Release

Compare
Choose a tag to compare
@dmytro-landiak dmytro-landiak released this 03 Apr 11:44
· 508 commits to main since this release

Minor release with the following features, improvements, and bug fixes.

Main features:

  • #94 MQTT 5: Request-Response Pattern;
  • #98 MQTT 5: Flow Control;
  • #101 UI: WebSocket client page; WebSocket connections and subscriptions entities support in Postgres.

Improvements:

  • Core and install scripts:

    • #104 TLS Cipher suites control - allows to set desired cipher suites usage;
    • #109 Backpressure improvements;
    • #110 Disconnect client command now includes Reason Codes to correctly specify the reason of the disconnection;
    • #111 MQTT over WebSockets installation scripts update for correct WebSocket client usage;
    • Added system WebSocket MQTT client credentials;
    • Application persistent and Application Shared Subscriptions clients workflow improvement by leveraging cached thread pool;
    • Non-blocking deletion of old Kafka consumer groups on broker startup;
    • Memory usage and performance improvements.

Bug fixes:

  • Core:

    • #106 Fix for direct memory leak;
    • #107 Fix for unauthorized delivery of Last Will message;
    • #94 Fixed Maximum Packet Size response to MQTT 5 client depending on the listener chosen;
    • Fixed NPE that can happen on broker startup during historical statistics calculation;
    • Disabled Redis autoconfiguration in case of Caffeine cache usage to prevent trying to connect to Redis instance on broker startup;
    • Dependency vulnerabilities;
    • User password containing only whitespaces bugfix.
  • UI:

    • #108 Fix for issue during Retained message deletion that contains special characters;
    • Resolved an issue with hidden fields in edit mode for MQTT client credentials details of the type "X.509 Certificate Chain".

Obsolete environment variables:

  • TB_APP_PERSISTED_MSG_THREADS_COUNT;
  • TB_APP_PERSISTED_MSG_SHARED_SUBS_THREADS_COUNT.

These environment variables can be safely removed due to automatic scaling of threads based on the number of Application clients being added or removed.