| Re: [hono-dev] Command & Control response buffering |
|
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? 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,
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marc Pellmann 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@xxxxxxxxxxxx> wrote:
|