On Mar 26, 2014, at 09:53 , ybronhei <ybronhei(a)redhat.com> wrote:
On 03/25/2014 03:15 PM, Francesco Romani wrote:
>
> ----- Original Message -----
>> From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
>> To: "Francesco Romani" <fromani(a)redhat.com>
>> Cc: "vdsm-devel" <vdsm-devel(a)lists.fedorahosted.org>, "Yaniv
Bronheim" <ybronhei(a)redhat.com>
>> Sent: Tuesday, March 25, 2014 1:45:22 PM
>> Subject: Re: thread pool implementation
>>
>> The thing that worries me the most is stuck threads.
>> I hate them!
>>
>> Could we move to multiple libvirt connections scheme?
>> Where if a call takes too long we just close the connection.
>> I know that the call is still running in libvirt but then it's
>> their problem and not my problem. That way the thread pool
>> doesn't need to handle this use case making it much simpler.
>>
>> Because apart from the problem of libvirt calls getting stuck
>> we just need a run of the mill threadpool solution.
>
> It is an interesting point.
> I'll investigate the multiple libvirt connection Idea.
>
we support multiple libvirt connections with libvirtconnection.py. however, vdsm uses
only one instance during its run. might be that this was the initial thought of the
libvirtconnection get function. but still, if the request gets stuck, how multiply
connections help us? we still need threads to avoid freezing other flows. afaiu you plan
to cover each libvirt call in a thread from the pool? we can still use one connection for
that. if each thread will establish new session to libvirt, it might cause very long delay
(depends on the load)
another thing to consider is the number of worker threads on the libvirt side (set to 20
by default now IIRC, some are used internally)
> Bests,
>
--
Yaniv Bronhaim.
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel