Re: [ovirt-devel] [VDSM][sampling] thread pool status and handling of stuck calls
----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: "Nir Soffer" <nsoffer(a)redhat.com>
Cc: "Francesco Romani" <fromani(a)redhat.com>, devel(a)ovirt.org,
"Michal Skrivanek" <mskrivan(a)redhat.com>, "Federico
Simoncelli" <fsimonce(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>
Sent: Sunday, July 13, 2014 5:43:28 PM
Subject: Re: [ovirt-devel] [VDSM][sampling] thread pool status and handling of stuck
calls
[...]
> The current patches do not change libvirt connection management
> this is orthogonal issue. They are only about changing the way
> we do sampling.
As I've been saying, I think the problem is in actually in the
libvirt connection management and not the stats operations.
Well yes, I think to have a better libvirt connection management is
another way to reach the go, granted it could detect and signal to
the upper layer a stuck call.
With that in place, the sampling code is simpler, and no need
for fancy thread pool. Even though we may need something like this
in the connection handling code internals.
*Maybe* a supervisor-like approach like my very first proposal could
work, but a very good point made by Nir is how to tell when something is
'stuck', since only tasks really know their timeout.
For sampling it is easy, is the sampling interval, but how to convey
this timeout in a generic manner to the connection layer?
Bests,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani