| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Xen-changelog] Added exception handler for Protocol
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
|
|
|
| |
|
Home