Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Event northbound delivery validation

Hi Francois,


thanks for your interest in Hono :-)


The Event API has been designed specifically for supporting your kind of use case, i.e. it is there in order to allow for an "at least once" delivery of event messages to back end consumers (your business application).


Depending on your use case it might or might not be necessary/helpful to store-and-forward events in a broker. In the default configuration, Hono uses "store-and-forward" semantics by means of the Artemis broker. In this configuration, Hono indeed requires the broker to acknowledge "ownership" of events sent to the broker. This "acknowledgement" is also propagated upstream to the protocol adapter that received the event from the device. If the device communication protocol allows for it, the successful reception of the event will be indicated to the device as well, e.g. when using MQTT QoS 1 a corresponding MQTT PUBACK message is sent back to the device.


On the consumer side the default configuration currently does not use "at-least-once" delivery semantics but "at-most-once". This makes sense for telemetry data but should be changed for events. We haven't yet made the required change to the default configuration but we already know what needs to be done.


However, if your use case does not require "store-and-forward" and you'd rather have the events being forwarded from the device to your back-end service directly using "at-least-once" delivery semantics then you should be able to do that already by means of simply removing the broker waypoint from the Dispatch Router configuration. In this case the application will acknowledge the reception of each event to Hono which in turn will forward the acknowledgment to the protocol adapter and (ultimately) to the device. Be aware, though, that in this case the device needs to handle re-deliveries and credit starvation if the business application is not able to process the events at the rate they get produced by the devices.


HTH


Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of François Travais <francois.travais@xxxxxxxxxxxxxxx>
Sent: Wednesday, May 31, 2017 16:08
To: hono-dev@xxxxxxxxxxx
Subject: [hono-dev] Event northbound delivery validation
 
Hello everyone,

I have a question regarding events delivery. For us an event is quite precious and we really don't want to loose any. Thus we would like the device to know if an event hasn't been saved properly in order to send it again. But this doesn't seem possible right now using Hono.

I'm not sure if I understood everything but to me it looks like Hono acknowledge that the event has been delivered as soon as it arrives in the AMQP broker (or maybe even before?). The problem is that at this point we don't know yet if the event is acceptable from the business application point of view. Furthermore if the business application dies before persisting the event we would loose it for good. I was thinking that the best way to tackle this would be to have a reply queue that goes all the way to the device. This way the business application could send a message back to the device to either confirm or decline the event.

I don't know how that could be implemented in the HTTP Protocol Adapter but it would work like a charm with the MQTT adapter.

Could you please tell me if I understood correctly how the event delivery happens and if the solution I'm proposing could work?

Best regards,

--
François Travais
Software Architect
Noiseless Acoustics

Back to the top