>>> On 7/11/2008 at 11:15 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 09:29:06AM -0600, Brad Nicholes wrote: >> >>> On 7/11/2008 at 5:02 AM, in message <[EMAIL PROTECTED]>, Carlo >> Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: >> > >> > It is definitely unstable and not likely to be fixed before the freeze, so >> > IMHO would be better deleted (not turned off by default) as there is no way >> > to do that reliably in a clean way AFAIK. >> >> Disabling it is just a matter of a file name change from tcpconn.py to >> tcpconn.pyoff or something like that. The same thing would have to be >> done for the tcpconn.pyconf file as well (tcpconn.pyoff). > > That is what I meant by "not in a clean way", as it will leave dead code > around and will get most likely people confused by the funny names and > will require them to rename files (which are under a package manager and > then will complain as being missing and won't be removed at uninstall > time obstructing the removal for other directories as well). > > in any case, if documented clearly I have no reason to object but that is > just because I won't be affected anyway as I don't use our provided > RPM packages. > > but on that line, remember that it might not be implemented the way you > envision for all available packages (which is what I meant by unreliably) > as the copying of the files is done now by the SPEC and that could result > in even more confusion. >
I guess I would just rather see it distributed so that the user can decide what they want to do rather than us making the decision for them. >> I would suggest we just make the file name change and still distribute it >> for those that want to use it anyway. > > My suggestion was to make a file name change as well into the contrib > directory, where it won't get in the way and will be also available for > those that want to use it, but since there is no contrib yet distributed > then cleanly removing it (it will be available from our repository in > the web anyway for whoever wants to install it) looks like the best next > option. > I would agree as well if we had a contrib/ directory. But just because we don't should not mean that we remove it completely and make it unavailable for those that would still like to use it. >> It still works reliably, it just has a wait timeout issue that is really >> only noticeable when using the -m parameter. > > but that would result in some metric samples failing silently and therefore > in some wholes in the RRD values that could then result in mysterious drops > in the graphs or flat lines. > No and the reason why is because the actual gathering of the data is threaded. tcpconn.py spins up its own gathering thread that periodically exec's netstat and updates an internal array of metrics. When the gmond main thread requests the metrics, all it does is read the internal array and return whatever the last gathered value was. There is no delay to gmond at all. At worst, the tcpconn gathering thread might delay occasionally which has no effect on anything else. It was written this way on purpose so that gmond would never be at the mercy of the python exec code, netstat delays in execution or OS delays. The delay only shows up for gmond when the tcpconn metric_clean() function is called and the main gmond process has to wait for the tcpconn gathering thread to shutdown. That's why you see the delay in with the -m parameter and no where else. The gmond -m option causes the metric_init(), which starts the gathering thread and the metric_cleanup() which shuts down the gathering thread, to happen one immediately after the other. Gmond has to delay waiting for the thread cleanup. Also tcpconn.py takes a RefreshRate parameter that can be set in the tcpconn.pyconf configuration file. This parameter determines how often the tcpconn gathering thread should attempt to exec netstat to get a new value for the internal structure. The gathering of the netstat value and the gathering of the gmond metric can be on two different cycles for the simple fact that latency can't be pre-determined. This issue really is just a -m parameter annoyance. Brad ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
