What is New in HiveMQ 4.8?

The HiveMQ team is excited to announce the release of HiveMQ 4.8. This release brings to you new security features to protect your data from edge to the cloud, improved reliability when working with multiple clusters, and saving you resources when managing Kafka-to-MQTT mapping at scale.

Highlights

• Secure data exchange between your broker and databases
  • The ability to secure connections to on-premises and cloud databases with the HiveMQ Enterprise Security Extension
• Enhancements to Bridge and Kafka Extensions
  • Looping prevention when bridging clusters
    • Averts situations where message streams get stuck in a loop between clusters and creates a message storm.
  • Automatic configuration of resources for Kafka-to-MQTT
    • Helps keep processing latency and throughput in-check for high-scale implementations.

Secure data exchange between your broker and databases

HiveMQ 4.8 enhances the Enterprise Security Extension via TLS to secure the transmission of credentials data between the broker and the on-premises (or cloud based) database of your choice.

This helps you make more secure architectural choices including using the public internet to securely connect your HiveMQ broker to a cloud-based database.

Technically, if the TLS connection fails, the broker will flag it as “unable to connect”. The benefit is that even in case of a network breach, highly sensitive credentials data is secure.

Implementation Enhancements to HiveMQ Bridge Extension and HiveMQ Enterprise Extension for Kafka

HiveMQ is constantly adding features that help customers operate their IoT estate with ease and confidence. In this release, we are bringing to market two unique enhancements that will help you accelerate your IoT journey.

Looping prevention

When bridging broker clusters, typically the ones that are in different locations (or managed by different teams), there is an inherent operational risk. This risk is that the configuration on the clusters may not be cohesive enough to ensure that no inter-cluster stream of messages gets stuck in an infinite loop.

For the users of our Enterprise Bridge Extension, this release helps mitigate this risk. Even when there is an inadvertent overlap in topic names between clusters, the extension ensures there are no duplicate messages or message storms between clusters.

Note: This feature utilizes the User Properties field which is only available in MQTT 5.

Automatic configuration for Kafka-to-MQTT

Each Kafka-to-MQTT topic mapping in the HiveMQ Kafka Extension has a dedicated Kafka consumer. In the HiveMQ cluster, all Kafka consumers for the same topic mapping are combined in one consumer group. The number of Kafka-to-MQTT topic mappings equals the number of consumer groups.

When adding a high number of Kafka-to-MQTT mappings, the increase in the consumer groups can lead to latency and throughput issues which are difficult to manage with Kafka. Engineers have to spend resources to manually fine tune things like thread pools and client buffers to keep the integration within healthy parameters of performance.

With this enhancement, the HiveMQ Kafka extension will automatically allocate the appropriate resources to ensure there is no increase in the processing latency or decrease in throughput of the broker cluster.

About Gaurav Suman

Gaurav is the Director of Product Marketing at HiveMQ. He is an engineer by education, and is passionate about helping businesses thrive with the help of technology.

Contact Gaurav