[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Changes in settlement of telemetry and dispatch router config?
|
On 20/09/17 17:00, Hudalla Kai (INST/ECS4) wrote:
Since Hono was never meant to be
another message broker, I think that the decision to set up a system
like proposed by you, should be up to the user/admin. The AMQP network
is not per se considered to be a part of Hono itself. So I guess our
approach should be to allow Hono to be used within as many system
designs as possible.
Makes sense!
The question therefore is more: do we prevent Hono
from being used in the way you describe if we send Telemetry messages
unsettled? Or would this even be a requirement?
I would say no to both (and indeed the user/admin *could* still
configure the AMQP layer to e.g. be something like a router using
multicast that drops messages if they so desire).
Personally, I do not think that the use case of multiple independent
subscribers of telemetry messages should be implemented using brokers
but instead using something like Apache Kafka that is hooked up with
Hono ...
Just to be clear, I did not mean that supporting multiple independent
subscribers requires a broker (that is what the routers multicast
distribution does also, but with no store-and forward guarantee). I just
meant that the choice between multicast and balanced is one between
non-competing and competing consumers. If you want at-least-once with
non-competing consumers, you will need some form of store-and-forward. I
agree Kafka is a good solution to that also.
[...]
I guess our intent with changing the disposition handling for Telemetry
is exactly to allow for back pressure being pushed all the way upstream
to the protocol adapters and devices so that we can prevent the
(unnecessary) messages from being sent in the first place (instead of
having to dispose of them somewhere in between the sender and consumer).
Makes sense.
