Re: Re: [Xen-changelog] Added exception handler for ProtocolError.

[Anthony Liguori <aliguori@us.ibm.com>]

Ewan Mellor wrote:
> On Thu, Mar 23, 2006 at 10:24:42AM -0600, Anthony Liguori wrote: 
>   
>> Hi Ewan,
>>
>> ProtocolError's shouldn't happen.  The case where os.geteuid() != 0 is a 
>> possibility (although I thought we had a check earlier for that?).  
>> However, if we are getting them for another reason, something's wrong.
>>     
>
> I wasn't sure whether you'd get a ProtocolError or an IOError if you tried to
> connect to the socket as non-root, so I just threw the geteuid test in -- if
> we can confirm that it's not needed (i.e. you are guaranteed to get an
> IOError) then we can do without that.
>
> The ProtocolErrors in general were being thrown whenever an exception made it
> all the way back to the top of a function registered with the server (i.e. any
> of our message handlers).

Yeah, in xen.util.xmlrpclib2:TCPXMLRPCServer::_marshaled_dispatch() we 
should catch any exception and convert it to a proper xmlrpclib.Fault.  
If exceptions are getting past that, there's something wrong.

I'll look at it today and see if I can't figure out what's happening.

Thanks for all your effort in merging this stuff Ewan!

Regards,

Anthony Liguori

>   These exceptions would get translated to a 500
> Internal Server Error which would appear at the client as a ProtocolError.  I
> don't know whether it is any exception that causes this, or only ones that
> inherit from StandardError or something like that.  One particular trigger was
> XMLRPCServer.dispatch, which wasn't checking the return value from lookup.
> This caused it to try and call None as a function whenever the user specified
> a domain that did not exist.
>
> Ewan.
>