Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
0.9
This release concludes the changes made in the area of collecting and reporting metrics that have been started in 0.8. In particular,
- the meter types, names and tags used by Hono for reporting status information have been revised and adapted to provide more relevant information for monitoring a Hono installation.
- Hono's protocol adapters and services by default expose an HTTP endpoint that can be used by a Prometheus back end to scrape metrics.
- the Graphite based legacy metrics format is still supported but users are encouraged to use the Prometheus back end instead.
The MQTT protocol adapter now supports
- publishing of command messages to devices using QoS 1 which allows back end applications that send commands to an MQTT device to be notified of a successful attempt to deliver a command to a device.
- authentication of devices using X.509 client certificates. The client certificates are validated using a trust anchor that can be configured at the tenant level.
With Hono 0.9 we have put a lot of effort in improving robustness and stability. This is reflected by the addition of timers in arbitrary places in the establishment and handling of AMQP connections and links, which help with recovering from situations where communication peers behave non-compliant with specifications or simply break away.
The (thorough) changes in the area of metrics reporting have been made in order to improve Hono's operability, e.g. by means of providing more detailed information with regard to the processing of messages received from devices and/or back end applications. For example Hono now reports the time it took to process each message and also reports the outcome of processing a message, e.g. whether the message has successfully been forwarded or could not be processed.
Hono has already provided support for tracing the processing of a message within the protocol adapters. The base classes for implementing the Device Registration, Credentials and Tenant APIs now also support deserialization of the tracing context propagated by the protocol adapters and thus allow extending the traces to the concrete implementations of these APIs.
The base classes provided by Hono for implementing the Credentials API now support clients to register a hashed-password by means of providing a plain text password instead of the password hash. While this sounds less secure at first, it actually helps with improving overall security because it prevents users from using weak hash functions. The plain text password will be hashed on-the-fly before going to the persistence store using a configurable (strong) hash function. By default, BCrypt is used for this purpose.
After a phase of deprecation the Hono Messaging component has been removed altogether from Hono.
- Log in to post comments