[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [Xen-changelog] Added exception handler for ProtocolError.
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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |