HiveMQ 4.5 Release

The HiveMQ team is pleased to announce the release of HiveMQ 4.5. This is a Long Term Support (LTS) release with new features and massive performance improvements for many use cases. This release also optimizes the memory footprint for large deployments and further increases stability, reliability, and scalability for large clusters.

Highlights

The highlights of the 4.5 release include:

• Long-term support version
• New Kafka to MQTT transformer
• REST service for the HiveMQ Enterprise Extension SDK
• Metrics for the DNS Extension used for Kubernetes
• Significant performance and memory improvements for large clusters.

Let's look at the highlights in detail:

Long Term Support

The default HiveMQ support policy covers all minor releases for one year. For customers who require longer update cycles, our long-term support (LTS) releases automatically include two years of support with an option to extend the support period for an additional year.

HiveMQ 4.5 is an LTS release, which means the version is supported until January 2023. Customers receive ongoing security and maintenance updates for the version up until that date and are eligible for hotfix versions.

LTS versions give customers who prefer conservative upgrade cycles or want to skip new features and functionality the possibility to remain with a version for up to 3 years along with the peace of mind that support and security updates are covered.

Kafka to MQTT Transformer

The previous HiveMQ version introduced a Kafka Customization SDK for the popular HiveMQ Enterprise Extension for Kafka. Our Kafka extension allows users to bi-directionally integrate MQTT messages with Kafka. This makes it possible to write MQTT streams to Kafka, consume Kafka topics, and move the data to IoT devices in an exceptionally scalable manner. The Kafka Customization SDK allows you to programmatically modify MQTT messages with custom code to achieve sophisticated integrations that realize even the most complex use cases. MQTT messages can be transformed on the broker to the format that Kafka needs.

HiveMQ latest adds the possibility to modify Kafka messages on the MQTT broker before they are sent to the MQTT clients. The new Kafka to MQTT transformer lets you enrich data, completely modify payloads, and integrate third-party systems into the modification process. The new capabilities enable use cases that need to consume a single Kafka message and then send the Kafka message to multiple MQTT clients on multiple topics with potentially varying payloads or other metadata. For example, MQTT 5 user properties.

Learn more about the Kafka Customization SDK as well as the new Kafka to MQTT Transformer in our documentation.

REST Service for The HiveMQ Enterprise SDK

HiveMQ offers a rich SDK that can modify virtually every aspect of broker behavior. With simple Java code, customers can create custom logic for modifying MQTT messages as well as programmatic integrations to practically any third-party system. For customers and partners, we also offer an extended expert-only SDK version that adds the ability to have high-performance integrations with third-party systems, custom views to the HiveMQ Control Center, and many more features that are exclusively available in the HiveMQ Enterprise SDK.

HiveMQ 4.5 now also adds a REST service that allows customers to create new REST APIs easily by extending the HiveMQ REST API.

Performance Improvements

HiveMQ 4.5 provides dramatic performance improvements for customers with large deployments. The cluster join and leave time is significantly reduced as well as replication times for queued messages, retained messages, and other data. Most workloads will experience an up to 50% improvement. Large shared subscriptions with numerous subscribers and messages are experiencing up to a 100% performance improvement. Additionally, we have further optimized the handling of large messages and reduced the memory footprint for particular scenarios by a factor of eight.

Metrics for DNS Extension

HiveMQ 4.4 shipped with a new HiveMQ Kubernetes Operator that makes it easy to deploy, operate, and scale HiveMQ deployments on Kubernetes environments. The advanced cluster technology of HiveMQ allows for dynamic and elastic auto-scaling. On Kubernetes, the best way to autoscale the broker is to use the DNS extension that is used by the Kubernetes operator. This DNS extension can also be used by customers to manage their deployments manually. The new version of our operator contains an updated DNS extension with additional metrics that allow users to observe if DNS requests were successful or unsuccessful as well as the number of cluster members found in DNS resolution. This information is useful to monitor if Kubernetes DNS hiccups are observed that affect the cluster.

Full List of Features and Improvements

Features:

• New metrics for successful and unsuccessful DNS discovery and the number of resolved IP addresses
• New REST service for easily creating HTTP APIs with the HiveMQ Enterprise Extension SDK
• New Kafka to MQTT transformer that significantly enhances the HiveMQ Kafka Extension Customization SDK

Performance Improvements:

• Improved replication performance at shutdown by nearly 50% for most workloads
• Improved memory usage for large client queues
• Better memory usage for the replication of large message queues during cluster topology changes with 10x improvement in memory consumption
• Improved replication performance for retained messages during cluster topology changes
• Improved performance for shared subscriptions with large numbers of subscribers and queue entries by >100%
• Reduced memory footprint for dealing with large MQTT messages - in some scenarios by factor 8x

Bug Fixes

• Corrected issue that could cause incomplete client queue replication
• Fixed an issue that could cause data to be lost when a node is stopped while another node joins the cluster.

Improvements

• New option to override the default destination of automatically-generated heap dumps to facilitate troubleshooting in containerized environments
• Increased memory efficiency for the publication of large payloads (10MB+)
• Improved handling of shared subscriptions that have large numbers of inflight messages
• Enhanced replication performance when a node leaves the cluster
• Better memory usage for the replication of large message queues during cluster topology changes
• Improved replication performance for retained messages during cluster topology changes