[ovirt-devel] [VDSM][sampling] thread pool status and handling of stuck calls

Francesco Romani fromani at redhat.com
Wed Jul 16 05:28:09 UTC 2014


----- Original Message -----
> From: "Nir Soffer" <nsoffer at redhat.com>
> To: "Francesco Romani" <fromani at redhat.com>
> Cc: devel at ovirt.org, "Michal Skrivanek" <mskrivan at redhat.com>, "Federico Simoncelli" <fsimonce at redhat.com>, "Dan
> Kenigsberg" <danken at redhat.com>, "Saggi Mizrahi" <smizrahi at redhat.com>
> Sent: Tuesday, July 15, 2014 7:28:51 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.
> 
> Can you explain how do you solve the sampling issue with better
> connection management?
> 
> Since libvirt does not have async api (yet), it seems that this
> would just move the thread pool to the connection layer.

Exactly like that.

I'm not very happy with this approach. More precisely, I can't see a satisfying way
to implement this approach, thus I prefer to go ahead with the route we already took.

Bests,

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani



More information about the Devel mailing list