Hi,

just tested, yup - it works, and you are right, strcmp is required.
Thanks.

But I still think you need the else to set xmldata->old to 0.
If not done, surely this will mean that the variable gets stuck on 1
for subsequent clusters/grids after the first old cluster is
encountered.
There is no code anywhere to set it to zero subsequently that I can see.
Am I missing it?

kind regards,
richard

-----Original Message-----
From: Martin Knoblauch [mailto:[EMAIL PROTECTED] 
Sent: 21 March 2006 12:14
To: Grevis, Richard: IT (LDN); ganglia-developers@lists.sourceforge.net
Subject: Re: [Ganglia-developers] Possible bug in hosts up calculation
when federating clusters.


Hi Richard,

 oops. You are both right and wrong :-) Looking at the code and comments
for "old", it seems that the whole logic is pre-3.0. It was used to
distinguish between 2.5.x and prior versions. For that purpose the code
is right. Of course, it now fails when it encounters the 3.0.X string.

 Something like this should solve it. Care to test? I am not sure about
setting old to 0 in the other case. In any case, the whole xmldata_t
structure is initialized early on.


diff -u -r1.45 process_xml.c
--- process_xml.c       18 Nov 2004 20:14:31 -0000      1.45
+++ process_xml.c       21 Mar 2006 12:09:16 -0000
@@ -821,7 +821,7 @@
          if (xt->tag == VERSION_TAG)
             {
                   /* Process the version tag later */
-                  if(! strstr( attr[i+1], "2.5." ) )
+                  if( strcmp( attr[i+1], "2.5." ) < 0 )
                      {
                          debug_msg("[%s] is an OLD version",
xmldata->ds->name);
                          xmldata->old = 1;


Cheers
Martin

--- [EMAIL PROTECTED] wrote:

> All,
> 
> when I had debugging turned on in gmetad, the daemon was announcing 
> data sources
> as old, when they were not. Looking at the code, 3.0.2 or 3.0.3
> gmetad/process_xml.c, line 821 or so, function
> startElement_GANGLIA_XML:
> <snip>
>          if (xt->tag == VERSION_TAG)
>             {
>                   /* Process the version tag later */
>                   if(! strstr( attr[i+1], "2.5." ) )
>                      {
>                          debug_msg("[%s] is an OLD version",
> xmldata->ds->name);
>                          xmldata->old = 1;
>                       }
>              }
>        }
> </snip>
> 
> It seems there are two problems here. First, is not the strstr test 
> the wrong
> way round? Second, if it is a new version of ganglia, xmldata->old
> should be
> explicitely set to zero. This seemed to make it better:
> <snip>
>          if (xt->tag == VERSION_TAG)
>             {
>                   /* Process the version tag later */
>                   if( strstr( attr[i+1], "2.5." ) )
>                      {
>                          debug_msg("[%s] version %s is an OLD
> version",
> xmldata->ds->name, attr[i+1]);
>                          xmldata->old = 1;
>                       } else {
>                          debug_msg("[%s] version %s is a NEW version",
> xmldata->ds->name, attr[i+1]);
>                         xmldata->old = 0;
>                         }
>              }
>        }
> </snip>
> 
> You actually don't notice the problem if your clocks are well 
> syncronised everywhere, because when clusters/grids are tagged as old,

> it does the up/down calculation from
> the current time, and it still works.
> 
> What do you guys all think?
> 
> kind regards,
> 
> Richard Grevis
> CTO wallah,
> Barclays Capital
> 


------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de


------------------------------------------------------------------------
For more information about Barclays Capital, please
visit our web site at http://www.barcap.com.


Internet communications are not secure and therefore the Barclays 
Group does not accept legal responsibility for the contents of this 
message.  Although the Barclays Group operates anti-virus programmes, 
it does not accept responsibility for any damage whatsoever that is 
caused by viruses being passed.  Any views or opinions presented are 
solely those of the author and do not necessarily represent those of the 
Barclays Group.  Replies to this email may be monitored by the Barclays 
Group for operational or business reasons.

------------------------------------------------------------------------


Reply via email to