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. > > 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. cheers, Gerd
