Hi -
> The original pmcd <--> pmda protocol was designed to accommodate _exactly_
> this sort of longish delay on pmda startup.
> [...]
> We need to go back to libpcp_pmda first and figure how to do this
> safely (my first guess is that it requires a new variant of
> pmdaConnect that can be safely called before pmdaInit and then
> possibly launching a worker thread [...]
Interesting approach - indeed there seems to be little else we can do
if we want both timely responses but tolerate potentially
indefinitely-long pmda processing. (The same tolerance for
pmdaNOTREADY could conceivably also apply to regular pmda traffic,
past initialization.)
It would be ideal if we could hide any required multithreading within
libpcp_pmda, rather than force the complexity to appear within the
API, or force all the pmdas to copy it. We'd have to be particularly
careful about interfacing perl/python VMs with an appropriate
set of (1?) threads. (Please note that the robustness of
multithreading support in libpcp* may not be as good as its sole user
(pcpqa) may lead one to believe; I recall seeing some problems in an
earlier review. These bugs might crawl out from under the rocks if we
kick them over.)
A lower complexity alternative solution could be to have the pmda
contract with the pmcd a different timeout for various operations,
e.g., so a particular pmda's startup could be given up to a few
minutes of time rather than a few seconds. These values could travel
within a larger pmdaInterface struct, or perhaps a pmcd.conf
extension.
- FChE
|