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

Reply via email to