What's New in HiveMQ 3.2?
Written by HiveMQ Team
Category: HiveMQ Release
Published: November 4, 2016
We are pleased to announce the release of HiveMQ 3.2. This version of HiveMQ is the most scalable HiveMQ version ever and brings massive improvements in the cluster performance as well as single node performance. Although there are massive improvements under the hood, HiveMQ 3.2 is a drop-in replacement for HiveMQ 3.1. You can use our rolling upgrade mechanism if you are already using HiveMQ in clustered mode, so you don’t have any downtime of your MQTT deployment.
While HiveMQ 3.2 is primarily a performance and stability release with tons of improvements under the hood, there are of course many new features you’ll love:
Increased Cluster Performance
HiveMQ introduced the distributed and linearly scalable cluster in version 3.1. The new version improves latency between cluster nodes and reduces overall traffic significantly. The routing intelligence is more sophisticated than ever and advanced batching and traffic reduction mechanisms make sure to get the best performance possible. Many hundreds of thousands of messages per second between an arbitrary number of broker nodes are possible out-of-the-box with default configuration. Dockerized deployments are of course supported as well as classic VM or bare metal deployments.
The best thing is, that of course rolling upgrades are supported and you can even operate clusters with HiveMQ version 3.1 and 3.2 deployed simultaneously. We take rolling upgrades seriously.
HiveMQ now supports the PROXY Protocol which was pioneered by the HAProxy load balancer and is available in many load balancers nowadays. This protocol allows to forward information about the original MQTT client, like IP address or port, when the TCP connection is proxied by the load balancer. Both, version 1 and 2, are supported by HiveMQ transparently.
X509 client certificate authentication like the Common Name of the certificate can also be forwarded by the load balancer with the PROXY protocol implementation of HiveMQ. Besides the officially supported information from the PROXY protocol, HiveMQ supports custom PROXY protocol extensions. If your load balancer can forward custom information via TLVs, HiveMQ can read it. The best part is, that you can utilize all PROXY protocol information in your custom plugins, including custom information.
Plugin System Extensions
The new version brings new features for the free and open source plugin system that plugin developers are going to love.
Callbacks can now determine to which listener a MQTT client connected to. If you need to determine if a connection was made over SSL or websockets, you are now finally able to do this without any hassle.
It’s now also possible to disconnect MQTT clients programmatically. You can kick out the MQTT client forcefully on the server side and you can also prevent sending out LWT messages when the client gets disconnected. Plugin developers can of course disconnect a MQTT client that is connected on another cluster node, so this feature is fully available in clusters - as most HiveMQ plugin features.
Plugins that utilize HiveMQ’s internal HTTP server via the RestService have a lot more options that are useful for sophisticated JAX-RS scenarios. You can now add custom ExceptionMappers as well as ContextResolvers and custom MessageBodyWriters and MessageBodyReaders.
We listened and now introduced a new callback that gives you more control over how topic subscriptions are handled. While the popular OnSubscribeCallback allows you to inspect the whole MQTT SUBSCRIBE packet, there was no way to change the return code for the MQTT SUBACK message for each subscriptions (since this was typically done with Authorization). Setting custom return codes for subscriptions is now possible with the new OnTopicSubscriptionCallback that even allows to override subscription return codes from the authorization logic. Developers now get fine-grained control over subscriptions.
All HiveMQ users profit from the improvements under the hood in this release. We were able to make the memory footprint even lower in this release. Users will notice a even better overall performance and lower latencies in many cases.
Innovative Active Anti Amplification mechanisms are incorporated in this release, which improves memory consumption for huge fanout cases and improves the performance significantly for large messages.
Linux users now automatically utilize a new epoll integration which uses the edge-triggered interface instead of the level-triggered interface. This is beneficial in high scalability scenarios with lots of connected MQTT clients. This is completely transparent and you don’t need to change settings to profit from this improvements, it is used automatically for you if edge-triggered epoll is available.
Monitoring Made Easy
HiveMQ now includes 350+ metrics that allow to monitor virtually every aspect of the MQTT broker, including detailed metrics for the cluster that allow to find issues in the production environment before they become problems.
The most popular plugins for monitoring, the JVM Metrics plugin and the JMX plugin are now part of the HiveMQ core distribution, so these are installed by default to make monitoring as easy as possible for you.
The logging configuration is now auto-reloadable by default, so if you need to change the log level at runtime, you can do this now easily by modifying the included logback.xml. No restarts are required for changing the log level!
An often requested features was to have auto-reloadable Java keystores and truststores. We listened and now you can modify your keystores and truststores at runtime. If your SSL certificates expired or you need to change it, no restarts of the broker are required anymore. The broker will pick up the changes as soon as the files are changed on the file system.
There are many small improvements and new features in this release:
- The Diagnostic Mode now logs all relevant metrics so it’s even easier for you to get help by our awesome support team
- Configuration of external IP address for cluster nodes are now possible. This is useful if cluster nodes are behind NATs or if you are in cloud environments where your external bind address is not visible (e.g. AWS)
- Additional Shared Subscription Syntax: It’s now possible to replace the colons ( : ) in the shared subscription syntax with slashes ( / ).
- We included a diagnostics startup script that makes it even easier to start HiveMQ with diagnostic mode
- Encrypted communication with TLS is now possible between cluster nodes
In order to upgrade to HiveMQ 3.2 from HiveMQ 3.1, take a look at our Upgrade Guide.