Re: [Ganglia-developers] gmetad protocol and propagating errors back to the client
On Thu, Jan 22, 2009 at 6:55 PM, Carlo Marcelo Arenas Belon wrote: > the interactive port was designed to mimic the behaviour from the > original gmetad port which always returns the whole tree. why's that? if I wanted the whole tree I'd query the non interactive port, instead I'm asking for specific metrics so I should get them or nothing (or an error). Falling back to whole tree doesn't sound correct to me. > if your concern is about returning too much data and the request was > missing, it might be better then to return no tree information (which > should be also valid) I'm not sure what you mean here with "no tree information". Would the DTD + grid tag count as such? I see 2 cases: 1) bad request 2) some/all of the items do not exist 1) happens before root_report_start is ran, so we could easily return nothing or call root_report_start and end before closing the fd 2) happens after root_report__start has ran, so we could add each found metric and nothing for the non-existing ones, and then call root_report_end doing that in both cases you get valid xml with at worst a GRID tag that doesn't contain anything or contains multiple cluster tags for each requested metric and the non-existing ones missing, which should be enough of a hint to the client that they don't exist. would that do? -- "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
Re: [Ganglia-developers] gmetad protocol and propagating errors back to the client
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 wrote: From: Spike Spiegel 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
Re: [Ganglia-developers] gmetad protocol and propagating errors back to the client
On Thu, Jan 22, 2009 at 12:24:56PM +0800, Spike Spiegel wrote: > > 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. gmetad (before r1946 in trunk) has the following "protocol" to signal errors to the interactive port (or should have since it is obviously misbehaving as coded as shown by the sporadic errors) : 1) if request is not allowed by ACL, report and close socket, otherwise 2) if request can't be read from socket, report and close socket. 3) if request is malformed/missing/invalid, report and assume "/". invalid XML wasn't meant to be returned unless a severe error was triggered and only as a last result because the data was already being sent but the error couldn't be recovered for. > This imho is bad behavior and code should be added to inform the > client of the error. the interactive port was designed to mimic the behaviour from the original gmetad port which always returns the whole tree. > but before that's possible it needs to be agreed > how this communication should happen. if your concern is about returning too much data and the request was missing, it might be better then to return no tree information (which should be also valid) > 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. for the XML to be valid the header, the body and the footer had to be sent so this would again lead to broken XML. Carlo -- 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
[Ganglia-developers] gmetad protocol and propagating errors back to the client
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
