On 03/09/2018 03:00 AM, Peter Xu wrote:
OOB introduced DROP event for flow control. This should not affect old
QMP clients. Add a command batching check to make sure of it.
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Signed-off-by: Peter Xu <pet...@redhat.com>
---
tests/qmp-test.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
+ /*
+ * Test command batching. In current test OOB is not enabled, we
+ * should be able to run as many commands in batch as we like.
+ * Using 16 (>8, which is OOB queue length) to make sure OOB won't
+ * break existing clients. Note: this test does not control the
+ * scheduling of QEMU's QMP command processing threads so it may
+ * not really trigger batching inside QEMU. This is just a
+ * best-effort test.
+ */
+ for (i = 0; i < 16; i++) {
+ qtest_async_qmp(qts, "{ 'execute': 'query-version' }");
Would the test be any more robust if we could generate a single string
to send all at once, rather than multiple separate calls to
qtest_async_qmp() (the overhead in generating separate strings means the
monitor may have made progress before we send the next string). But
that can be a followup, if you want to pursue the idea.
+ }
+ /* Verify the replies to make sure no command is dropped. */
+ for (i = 0; i < 16; i++) {
+ resp = qtest_qmp_receive(qts);
+ /* It should never be dropped. Each of them should be a reply. */
+ g_assert(qdict_haskey(resp, "return"));
+ g_assert(!qdict_haskey(resp, "event"));
+ QDECREF(resp);
Should we also be sending unique ids, and ensure that the responses
arrive with ids in the same order? Again, idea for a followup.
Reviewed-by: Eric Blake <ebl...@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
