What’s new in HiveMQ 4.10?

What’s new in HiveMQ 4.10?

author portrait

Written by The HiveMQ Team

Category: HiveMQ Release

Published: December 6, 2022


The HiveMQ team is proud to announce the release of HiveMQ Enterprise MQTT Platform 4.10. This release focuses on automated checks and validations that make it easier to quickly and reliably configure and extend HiveMQ deployments.

Highlights

  • Enhanced reliability thanks to built-in configuration validation at startup.
  • Informative sanity checks to automatically verify configuration settings.
  • Improved resiliency through extended cluster overload protection.

HiveMQ Startup Configuration Validation

Our new schema-based configuration validation automatically checks your HiveMQ broker configuration at startup. Starting with HiveMQ 4.10, the HiveMQ broker ships with an XML Schema Definition (XSD) file that lists all the elements and attributes that can be used in a HiveMQ configuration.

How it works

HiveMQ uses the XSD file to check the values that are currently entered in your configuration XML file. If invalid settings are detected, the HiveMQ broker does not start and detailed information on each configuration error is provided in your HiveMQ log file.

How it helps

The explicit information that HiveMQ configuration validation provides in the HiveMQ log files makes it easier for development teams to successfully get a cluster up and running. Additionally, based on the config.xsd, XML editors and IDEs with schema support can offer prompts, options, and error indicators that simplify valid XML configuration of the HiveMQ broker.

  • Example log file entry when two listeners are configured with the same name. XML editors and IDE that have schema support will also highlight the entry as an error and generates a Listener name ‘listener’ already in use warning:
HiveMQ 4.10
  • Example schema-based error message when a TCP listener is configured with a port number that exceeds the maximum range. The specific line in the XML is directly highlighted:

HiveMQ Sanity Checks

To quickly identify critical issues that can prevent your HiveMQ implementation from functioning as expected, HiveMQ now automatically runs a brief set of tests to evaluate your current system configuration. This type of testing is commonly called a sanity check.

How it works

HiveMQ runs an initial sanity check at startup and repeats testing every 12 hours to catch any configuration changes made during runtime. Currently, each sanity check contains a test to verify the open-file limit on your system and a test to verify if all necessary file-access permissions for HiveMQ are correctly configured. HiveMQ logs a warning for each test in the completed sanity check that fails. The WARN log statement gives you detailed information about the test result and recommendations on how to correct the issue.

How it helps

The presence of a failed sanity check does not prevent HiveMQ startup. The purpose of the checks is to help you immediately identify inadequate or incorrect HiveMQ configurations and take appropriate action.

Example: log file entry when the currently configured soft open file limit for HiveMQ is lower than recommended:

Cluster Overload Protection for Subscribe Packets

HiveMQ provides built-in cluster overload protection that allows the HiveMQ broker to restrict incoming traffic if the rate of MQTT messages in the cluster becomes too high. Overload protection gives each HiveMQ node in your cluster the ability to temporarily prohibit traffic from individual MQTT clients that are significantly increasing cluster load.

How it works

Based on the current load, each HiveMQ node in a cluster can throttle incoming traffic to prevent resource exhaustion. HiveMQ 4.10 adds cluster overload protection for the number of incoming subscribe packets a node accepts.

How it helps

The selective application of back pressure on specific MQTT clients during periods of exceptionally high load improves the resiliency of your cluster. HiveMQ cluster overload protection mechanisms ensure that your cluster can recover from stressful situations without notable service degradation for most MQTT clients.

Get Started Today

To upgrade to HiveMQ 4.10 from a previous HiveMQ version, take a look at our HiveMQ Upgrade Guide. To learn more about all of the features we offer, explore the HiveMQ User Guide.

author HiveMQ Team

About The HiveMQ Team

We love writing about MQTT, IoT protocols and architecture in general. Our experts are here to help, so reach out to us if we can help!
mail icon Contact us

newer posts Part 1 - What is Unified Namespace (UNS) and Why Does it Matter?
HiveMQ 4.8.7 Maintenance Release older posts