Gerd Hoffmann <kra...@redhat.com> writes: > On Mon, May 27, 2019 at 10:18:42AM +0200, Markus Armbruster wrote: >> Marc-André Lureau <marcandre.lur...@gmail.com> writes: >> >> > Hi >> > >> > On Thu, May 23, 2019 at 9:52 AM Markus Armbruster <arm...@redhat.com> >> > wrote: >> >> I'm not sure how asynchronous commands could support reconnect and >> >> resume. >> > >> > The same way as current commands, including job commands. >> >> Consider the following scenario: a management application such as >> libvirt starts a long-running task with the intent to monitor it until >> it finishes. Half-way through, the management application needs to >> disconnect and reconnect for some reason (systemctl restart, or crash & >> recover, or whatever). >> >> If the long-running task is a job, the management application can resume >> after reconnect: the job's ID is as valid as it was before, and the >> commands to query and control the job work as before. >> >> What if it's and asynchronous command? > > This is not meant for some long-running job which you have to manage. > > Allowing commands being asynchronous makes sense for things which (a) > typically don't take long, and (b) don't need any management. > > So, if the connection goes down the job is simply canceled, and after > reconnecting the management can simply send the same command again.
Is this worth its own infrastructure? Would you hazard a guess on how many commands can take long enough to demand a conversion to asynchronous, yet not need any management? >> > Whenever we can solve things on qemu side, I would rather not >> > deprecate current API. >> >> Making a synchronous command asynchronous definitely changes API. > > Inside qemu yes, sure. But for the QMP client nothing changes. Command replies can arrive out of order, can't they?
