What's New in HiveMQ 4.6?

The HiveMQ team is pleased to announce the release of HiveMQ 4.6. This feature release is jam-packed with new functionality, attractive improvements, and introduces HiveMQ Swarm, the industry’s first MQTT load & reliability testing tool that enables organizations of all sizes to reliably simulate and test IoT applications at any scale, on any environment, and at any level of complexity.

Highlights

If you only have time for the top takeaways from this release, don’t miss these two new features:

• HiveMQ Swarm, our new and first of its kind testing tool for any IoT scenario.
• Dead Message Topic a new HiveMQ MQTT Add-on, that lets you conveniently identify which topics no one is interested in.

Let’s have a look at this release in more detail:

HiveMQ Swarm

IoT solutions usually involve massive distributed systems. Although MQTT system testing is imperative for every business-critical IoT solution, successfully simulating your end-to-end production environment can be a big challenge.

HiveMQ Swarm provides a distributed simulation environment for successfully testing millions of MQTT clients, messages, and topics as well as complete IoT scenarios. While doing so, an IoT use case can be realistically simulated, including special cases and individual characteristics of your use case, before it is deployed into production.

With HiveMQ Swarm, you can easily identify potential bottlenecks in your system and verify whether the countermeasures you apply effectively solve the problem. Once written, the HiveMQ Swarm scenarios you create are reusable, which makes it appropriate to integrate HiveMQ Swarm into your deployment pipeline to ensure ongoing testing and act as an additional quality gate for your system.

HiveMQ Swarm gives you the flexibility to simulate any IoT scenario you want to test for performance, scalability, and reliability before it goes into production. At the same time, HiveMQ Swarm is extremely resource-efficient and suitable for any public cloud such as AWS, Azure, or on-premise Kubernetes deployments.

Finally, HiveMQ Swarm provides immediate feedback on test results that can be visualized in our pre-defined Grafana dashboard. Naturally, you can also use this data to create customized dashboards that fit your specific requirements.

To sum it up: HiveMQ Swarm is an advanced IoT testing and simulation tool that gives you the load and reliability testing ability you need to determine the resilience and capacity of your complete IoT system.

Dead Message Topic

Messages that lack a receiving subscriber create wasteful loads on your IoT system. If no subscribers are interested in the information, it makes absolutely no sense to send the messages, especially if the messages are sent repeatedly. Identifying these messages can help you improve the stability and performance of your entire IoT system and lower your costs.

The Dead Message Topic is a useful addition to the HiveMQ MQTT Add-ons that we introduced in HiveMQ 4.4. Like the Expired and Dropped Message Topics, the Dead Message Topic helps you identify, analyze, and report all messages that do not have a receiving subscriber. This new topic also uses a reserved namespace to prevent conflicts with your existing workflows, applications, and security mechanisms. While the original message is kept, the additional information is provided in user properties to give you 100% compatibility with the MQTT 5 specification. In addition, these special analytical topics can be used with the HiveMQ Enterprise Extension for Kafka to forward the dead messages to your Kafka cluster for further processing.

New functionality for the REST API

Since its introduction, our HiveMQ REST API has helped a lot of customers to automate administrative tasks and interact with HiveMQ programmatically. Based on customer feedback, we’ve added some useful new features to the REST API. Now it is possible to disconnect MQTT clients programmatically and invalidate MQTT client sessions. This is especially helpful when you identify multiple MQTT clients that you need to manually reconnect. For example, to assign new credentials to the client, or remove them entirely from the system. Instead of searching for these clients manually in the HiveMQ Control Center, you can now do this programmatically, which saves you time and is less error-prone.

Enterprise Bridge Extension

With HiveMQ 4.4 we also introduced our Enterprise Bridge Extension that offers a scalable and secure solution to bridge between a HiveMQ cluster and any other MQTT broker, for example, to build a federation of multiple MQTT clusters or efficiently stream important data from restricted areas to a central data center for further processing. HiveMQ 4.6 contains an updated version of our Enterprise Bridge Extension that puts customer feedback into awesome new functionality.

With this new version, the Enterprise Bridge Extension can keep the retained flag for a message in both PUBLISH and SUBSCRIBE mode. This allows you to distribute retained message information across the entire hierarchical broker topology.

Full List of Features and Improvements

Features:

• Added new HiveMQ Dead Topic Add-on to automatically collect messages that do not have a subscriber.
• Added the ability to disconnect MQTT clients via the HiveMQ REST API.
• Added the ability to invalidate client sessions via the HiveMQ REST API
• Added retained message support to the PUB and SUB modes of the Enterprise Bridge Extension.
• Added retain as published subscription option for shared subscriptions.
• Added a new HiveMQ environment variable pattern that broadens support for environment variables in the configuration of HiveMQ and HiveMQ enterprise extensions.

Bug Fixes

• Fixed an issue in which memory-mapped files could cause an out-of-memory error.

Improvements:

• Adjusted access to the TLS information of MQTT clients in the HiveMQ extension system.
• Added ability to modify the assigned client identifier in CONNACK interceptor.
• Improved replication performance for clusters with large numbers of subscriptions to prevent high latency when a node leaves or joins the cluster.
• Adjusted overload protection behavior to ensure that affected clients are not disconnected due to an expired keep-alive