[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Command & Control response buffering
|
Definitely the buffer have to be restricted, for instance ttl (set with command request) & size (number of the command responses or their total size, controlled by the Hono).
You probably have similar issue with the events which, in my opinion, are expected to be even more (in terms of number and size) then the command response.
The point is that if I have monolithic solution adapter + backend app then both are simultaneously up or down. So if device reports command result - it could be stored if both are online. But when you have micro-service architecture adapter -> Hono -> server, the adapter + Hono may be up, the device may send result and if the backend app is down - the command result will be lost (without this buffering mechanism).
Поздрави / Best regards,
Avgustin Marinov
Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 | BULGARIA | www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 | Avgustin.Marinov@xxxxxxxxxxxx
-----Original Message-----
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Hudalla Kai (INST/ECS4)
Sent: 20 юни 2018 г. 17:36
To: hono-dev@xxxxxxxxxxx
Subject: Re: [hono-dev] Command & Control response buffering
On Wed, 2018-06-20 at 14:26 +0000, Marinov Avgustin (INST/ECS8) wrote:
> Hi Marc,
>
> but this applies event for instance commands? I mean even if the
> execution takes few seconds, the caller service could restart, or
> loose connection to the AMQP reply-to topic for a while. Why it should lose the reply?
> Also, sending the result for long living commands as events seems like
> bypassing the command’s request/response pattern/support. And which
> action I should model like that? Which takes 1 sec, 10 sec, 1 min?
I see your problem and I can in general sympathize with the idea of "buffering"
the responses. However, for how long should we buffer them? IMHO we should make sure that we do not end up piling up responses that nobody seems to be interested in anymore, right? So we should use a general TTL for responses in order to make sure that we don't run out of space.
> If reply is not buffered, than I will model all of my commands as
> command/reply event – then what I’ll benefit of command reply?
>
> Поздрави / Best regards,
>
> Avgustin Marinov
>
> Engineering Cloud Services Device Manager
> (INST/ECS8)
> Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124
> | BULGARIA | www.bosch-si.com Tel. +359 2 9055801 | Mobile +359 889
> 464664 | Fax +359 2 9532617 | Avgustin.Ma rinov@xxxxxxxxxxxx
>
>
>
> From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of
> Marc Pellmann
> Sent: 20 юни 2018 г. 14:09
> To: hono developer discussions <hono-dev@xxxxxxxxxxx>
> Subject: Re: [hono-dev] Command & Control response buffering
>
> Hi Avgustin,
>
> as written on the concept page the Command and Control API defines commands
> that follow a request-response pattern and expect an immediate confirmation of
> their result. But we do not define that this need to be the result of the
> execution of the command. The device could also immediately acknowledge receipt
> as part of the request-response-pattern.
>
> If the use case needs a later response (which then also needs the guarantee of
> delivery) the device is able to do such with a normal event. In such a case I
> would also assume that the application has some kind of persistence of the
> expected execution result correlation because it could not be sure, that it is
> the same instance who gets the response (this would also be the case if the
> response would arrive hours or days later on the direct response link - which
> not an intended case).
>
> Maybe it makes sense to define specific properties and e.g. content-type for
> such command-response events in later versions.
>
> Best regards,
> Marc
>
>
> On Wed, Jun 20, 2018 at 11:53 AM Marinov Avgustin (INST/ECS8) <Avgustin.Marinov
> @bosch-si.com> wrote:
> > Hi all,
> >
> > as far as I understand, currently, the responses (replies) for the commands
> > will be lost if there is no registered consumer. This could be a problem in
> > some cases. For instance if the command execution on the device side takes
> > too long – e.g. hours.
> > In that case when the response is returned the backend application may be
> > down and the result of the execution could be lost. I thing that it would be
> > better to have buffering of the command responses on in hono in order to
> > provide guaranties that the response of the commands will reach the backend
> > application. After all, such guaranties are available for the events. And the
> > command results are maybe event more important then events.
> >
> > What do you thing?
> >
> > Поздрави / Best regards,
> >
> > Avgustin Marinov
> >
> > Engineering Cloud Services Device Manager
> > (INST/ECS8)
> > Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 |
> > BULGARIA | www.bosch-si.com
> > Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 | Avgustin.
> > Marinov@xxxxxxxxxxxx
> >
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
_______________________________________________
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
