Le 15/07/2013 16:07, Jay Shaughnessy a écrit :
The ability to spin up non-shared Sigar instances may be OK to
handle
lock issues with the shared instance. Although, I'm not sure I like the
fact that we could spin up an unlimited number of these instances (which
could also hang) or the introduction of a reaper job. I already don't
like the number of timer jobs we have running, and in 5 minutes we could
have already accumulated a large number of jobs.
Could we instead introduce a more straightforward timeout for Sigar
requests? Either handled by the requesting thread itself, or even by
the waiting thread? Even if it meant killing the shared instance and
re-establishing a new one?
Perhaps better to have failed calls for unserviceable requests than to
let the shared instance hang.
If sticking with the suggested approach, we should at least have a limit
on the number of non-shared instances, and the reaper thread time should
be configurable.
Hi Jay,
The patch I'm going to merge has evolved. We will not let the number of
Sigar instances grow indefinitely. We will create up to 50 (by default)
on demand Sigar instances and then start to throw RuntimeException. This
will put the agent in a degraded mode similar to the mode where you
disable the native system.
Thomas