On Sun, Jan 18, 2009 at 9:08 PM, Carlo Marcelo Arenas Belon <care...@sajinet.com.pe> wrote:
> the proposed solution will result in a truncated XML which then will fail to > be parsed in the client and in an obscure error like "unable to write > XML tree info". > > agree that returning the whole tree isn't the best way to signal a > syntax error, but returning a truncated XML will be more difficult to > handle in the client side as depending on the implementation used it > will fail to even load with an exception. > > because the connection to the client is getting severed when it is > malformed it will also show strange errors like "unable to write root > preamble (DTD, etc)" or "Connection reset by peer" in the client. That is true, but afaics not a problem introduced by this patch. In the original version if by any reason process_path failed you'd log the msg, close the fd and go back to sleep, hence sending back an invalid xml since the DTD + root_report_start ran already but root_report_end won't. I agree that some kind of problem with process_path itself is a different case and less frequent than a typo, tho. Anyway, I'm absolutely for improving error propagation to the client, what do you suggest? Return an empty but valid tree? Or should an explicit error message be sent? In which case would it be possible to have an ELEMENT for that? 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