Hi guys: Wow... what a long thread...
IMHO, the best solution here is to look at apache's main loop implementation and adapt our code. This way, (hopefully) we will get what we want (late initialization) without modifying any apr code. Carlo, since you seem to be on a roll here, could you please kindly: 1) Take a look at the apache code and see if you can create a working patch against our source 2) Engage the apache/apr team to see if they could help us in that regard Let's try to get this issue resolved and move on. Thanks a lot guys! Bernard On Fri, Dec 11, 2009 at 8:56 AM, Carlo Marcelo Arenas Belon <care...@sajinet.com.pe> wrote: > On Fri, Dec 11, 2009 at 08:59:56AM -0700, Brad Nicholes wrote: >> >> APR is designed to solve these problems in a cross platform way and we >> are proposing that we abandon the cross platform solution in favor of a >> platform specific solution. > > Just want to clarify here that it is not a "platform specific solution" as > much as one based on fairly common UNIX standards and therefore supports > most likely every single of the platforms we run on including cygwin. > > In any case to simplify testing and probing me wrong a snapshot from trunk > with the patch included is available from : > > http://sajino.sajinet.com.pe/ganglia/ganglia-3.2.0.0.tar.gz > > There is yet no native windows ganglia (even if some work has been done > already to have a native metric version of libmetrics at least on trunk), > neither a novell network version (and eventhough I would be interested on > at least adding it to libmetrics lack the access needed to a development > environment which will allow one to exist most likely as noticed by the > lack of interest on it, otherwise) and so most of the portability of APR > (which in this case is just a small wrapper around fork) is not helping > much yet. > >> I know that httpd doesn't have these issues and they detach and run >> just fine across a wide variety of platforms including windows, BSD, >> solaris, etc. > > right, and that is why alternative 3 in : > > http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg05398.html > > says, look at the apache httpd implementation of their main loop and make > ganglia's similar so it will work with APR AS-IS. > >> Why are we having these problems when httpd doesn't? Is the real solution >> as simple as going to the APR mailing list and asking why this issue exists >> in APR and if there is a workaround? I haven't really seen this issue show >> up on the APR mailing list so far or did I miss it? > > it is obvious, as you explained before, that apache uses APR in a different > way than ganglia and that is why there is no "bug" to fix here in APR (except > the fact that the implementation of apr_poll is "leaky" as it is inconsistent > between platforms), if there is a bug I would say it is in the BSD > implementation of kqueue with its non inheritable file handles. > > I presume the reason why you haven't seen this show up in the APR list, is > because it makes probably more sense for the apache httpd list instead for > help understanding how apache is able to "work around" the leakiness of > apr_poll and that also requires some reading from apache's code (which I > am not at least that familiar with, neither really interested) > >> One of the problems that we already have with gmond is that there is >> already too much platform specific code in it which is why we have to >> rely on cygwin in order to run on windows. > > ganglia is a monitoring application, and therefore it is very likely to have > to work with very platform specific stuff anyway (unlike apache), I agree > though that using cygwin for windows is not ideal and I hope it will be > deprecated sometime when a native windows version would be available, but > APR so far hasn't help much in that direction AFAIK. > >> It is also the reason why gmetad doesn't really run on windows because >> it wasn't built on top of a cross platform solution. My gut feel is that >> we should be moving ganglia more towards APR rather than away from it. > > gmetad could be made to run on windows, and from time to time some pure soul > succeeds and then realizes why it was still reported as "dont even try". > > AFAIK the original reason behind having and alternative python implementation > of gmetad was to have to avoid having to go through the pain of cleaning that > code for portability, noting that it mostly works almost reliably in linux > at best, still I agree APR would be most likely part of a portable gmetad > if needed. > > Carlo > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Ganglia-developers mailing list > Ganglia-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
