eclipse-hono/hono 1.6.0

on GitHub

New Features

• Apache Kafka is now supported as a messaging system for events and telemetry messages.
  This can be enabled by configuring protocol adapters to use Hono's new Kafka-based
  client. Please refer to Hono Kafka Client Configuration for details.
• New APIs have been added for the Kafka-based messaging. Please refer to
  Telemetry API for Kafka and Event API for Kafka for the specifications.
• The MQTT adapter now allows clients to indicate whether they want the target device's tenant and/or device IDs
  to be included in the topic used when publishing commands.
• The caching behavior of the protocol adapters' AMQP based registry clients has been changed. All adapter
  Verticle instances now share a single cache instance per service. In particular, there is a single cache for
  all responses returned by the Tenant, Device Registration and Credentials service respectively.
  In addition, each cache is now being used for all responses to requests regardless of the tenant. Consequently, the
  service client configurations' responseCacheMinSize and responseCacheMaxSize properties now determine
  the overall number of responses that can be cached per service. In previous versions the properties determined
  the number of entries per client instance and tenant. The new approach allows for better control over the maximum
  amount of memory being used by the cache and should also increase cache hits when deploying multiple adapter
  Verticle instances.
  The org.eclipse.hono.adapter.client.registry.amqp.ProtonBasedTenantClient now makes sure that only a single
  request to the Tenant service is issued when multiple (parallel) get method invocations run into a cache miss.
  This should reduce the load on the Tenant service significantly in scenarios where devices of the same
  tenant connect to an adapter at a high rate, e.g. in when re-connecting after one or more adapter pods have
  crashed.
• The Device Registry Management API's update credentials operation has been extended to allow specifying the
  auth-id and validity period implicitly by means of including a (Base64 encoded) client certificate in the new
  cert property. This can be used instead of specifying the client certificate's subject DN and public key's
  validity period explicitly in the auth-id and secrets properties. This should make setting the correct auth-id
  value much less error prone.
• Hono now supports auto-provisioning of devices that connect via gateway. For more information please refer to the
  Device Provisioning concept and to the Device registry management API on how to create a device registration for a
  gateway which is enabled for auto-provisioning.
• The Device Registry Management API has been extended now to support searching tenants with optional filters,
  paging and sorting options. Please refer to the Device registry management API for details.
• The MongoDB based device registry now supports searching tenants with optional filters, paging and sorting options.

Fixes & Enhancements

• The Mongo DB based Credentials service implementation failed to return the credentials matching the given
  type and auth-id if multiple credentials of the same type but with different auth-id values were
  registered for a device. This has been fixed.
• The Mongo DB based registry container would have failed to start if the connection to the Mongo DB could not
  be established quickly enough. This has been fixed by decoupling the creation of indices from the start up process.
• The protocol adapters erroneously indicated a client related error to devices if the downstream AMQP container
  rejected a message with an amqp:resource-limit-exceeded error condition. This has been fixed so that the adapters
  now correctly indicate a server related problem instead.
• The containers for the Device Registry implementations, the Authentication server, the Device Connection and
  Command Router services did not shut down gracefully upon receiving a SIGTERM signal. This has been fixed.
• The LoRA protocol adapter failed to start due to a missing bean declaration. This has been fixed.

Deprecations

• The org.eclipse.hono.service.cache.SpringCacheProvider and org.eclipse.hono.service.cache.SpringBasedExpiringValueCache
  classes have been deprecated to further reduce the dependency on Spring Boot. Clients should use
  org.eclipse.hono.service.cache.CaffeineCacheProvider and org.eclipse.hono.service.cache.CaffeineBasedExpiringValueCache
  instead.
• Most of the public interfaces of the legacy client module have been deprecated. Client code should be
  adapted to use the corresponding interfaces and implementations from the clients/adapter, clients/adapter-amqp
  and clients/application-amqp modules instead.
• The Authentication server's HONO_AUTH_SVC_PERMISSIONS_PATH configuration property has been changed to no
  longer accept generic Spring resource URIs. The value is now required to be a file system path. The path
  may still contain a file:// prefix in order to not break existing configurations. However, users are encouraged
  to remove the prefix as it will no longer be supported in versions starting with 2.0.0.
  The default permissions file has been removed from the Authentication server code base. Consequently,
  permissions can no longer be loaded from the class path using a classpath:// URI. In practice this should
  have no impact because the Hono chart comes with a default permissions file which the Authentication
  server is pre-configured to load from the file system.