| Re: [hono-dev] Event northbound delivery validation |
Hi Kai,Issue submitted: https://github.com/eclipse/hono/issues/194 I can work on a fix and submit a PR. I may need some help but I'll post my questions in the github issue thread directly.Thanks for the quick response.On Fri, Jun 2, 2017 at 10:43 AM, Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx> wrote:Hi Francois,
I have been taking a look at the MQTT protocol adapter implementation. The current implementation does not wait for the downstream Hono Server's acknowledgment to send the PUBACK back to the device. This is clearly a bug.
Could you open an issue on GitHub so that we can track this problem and provide a fix?
We have only recently started to work on the Event processing functionality due to the lack of an appropriate version of the Artemis broker being available for some time. However, we do consider this to be a very important feature so I would really like to fix this. It would be great if you could support us in fixing this, either by providing a PR yourself or by means of verifying and testing the fix we provide :-) WDYT?
@Dejan: Could you please take a look at this thread and check if I am mistaken on any of my assumptions/statements?
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@nlacoustics.com >
Sent: Thursday, June 1, 2017 16:26
To: hono developer discussions
Subject: Re: [hono-dev] Event northbound delivery validationHi Kai,
Thanks for the answer.
I've tried to configure Hono the way you described but without success. I set MQTT QoS to 1 and removed the broker, no help. I'm willing to let the device handle re-deliveries and credit starvation.The device receive PUBACK even if there is no downstream consumer and when I plug the downstream consumer the device receive PUBACK before the message arrives to the consumer.I tried to debug what's happening using IntelliJ remote debugger but I'm new to VertX and I couldn't really find what I wanted.I found this line in EventConsumerImpl class: receiver.setAutoAccept(true) . I tried to change it but it didn't help.
I also found in AbstractSender that the send function returns right away:@Override
public final boolean send(final Message rawMessage) {
Objects.requireNonNull(rawMessage);
if (sender.sendQueueFull()) {
return false;
} else {
context.runOnContext(send -> {
sendMessage(rawMessage);
});
return true;
}
}
My repo point to the last commit: 0c42539ca11b6b334d4b204299c3fbcf90b39103.
Could you help me? I'm running out of ideas.
BR,
On Thu, Jun 1, 2017 at 12:55 PM, Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx> wrote:
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@nlacoustics.com >
Sent: Wednesday, May 31, 2017 16:08
To: hono-dev@xxxxxxxxxxx
Subject: [hono-dev] Event northbound delivery validationHello 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,--
Noiseless AcousticsFrançois TravaisSoftware Architect
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
--
Noiseless AcousticsFrançois TravaisSoftware Architect
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
--Noiseless AcousticsFrançois TravaisSoftware Architect
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev