Another thing that I noticed is that if you inject a metric into a gmond that
contains special xml chars, the gmetad fails to escape them on the way out. The
gmetad appears to be using xpat when picking up xml, which apparently handles
the special characters fine. But uses it's own serialization code which doesn't
handle any special chars.
To be clear I'm talking about these guys:
http://xml.silmaril.ie/authors/specials/
The only time you'll see this is if you're producing your own metrics with
string values that include any of the special xml characters. The result is
malformed xml causing the web-pages to break.
To further qaulify this issue, I have a custom-built application that exposes
xml to a gmetad that I use to create rrds and web-pages. My application is
performing the correct character replacements. I have not checked whether
submiting these types of strings directly to a gmond would work. After a quick
look at the code, it appears the gmond uses the same printf() style of xml
serialization as the gmetad. My guess is that the malformed xml would come from
the gmond too.
--- On Wed, 1/21/09, Spike Spiegel <fsm...@gmail.com> wrote:
From: Spike Spiegel <fsm...@gmail.com>
Subject: [Ganglia-developers] gmetad protocol and propagating errors back to
the client
To: ganglia-developers@lists.sourceforge.net
Date: Wednesday, January 21, 2009, 11:24 PM
Hi,
right now when gmetad fails an error is logged and in some cases the
connection to the client interrupted returning invalid XML or in other
cases (item not found or broken request) the entire tree is returned.
This imho is bad behavior and code should be added to inform the
client of the error, but before that's possible it needs to be agreed
how this communication should happen. I'm not really fond of XML or
ganglia's code, but I'd guess adding an ERROR element to the DTD is
possibly a solution. At that point whenever there's an error
root_report_start() should be called at the very least and an error
element added inside. This should also work nicely for the multi-item
per request patch I proposed elsewhere [1] as you'd have an error per
requested element.
If anybody is willing to lend a hand to kickstart the XML definition
(or whatever approach is best) I'd be glad to work on the rest.
thanks
--
"Behind every great man there's a great backpack" - B.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
