Mailing List Archive

XMLRPC behavior changed?
Hi
I am trying to connect to a remote XEN daemon using SSH tunnel (written using paramiko) . The servers have xend-tcp-xml-rpc-server is enabled. It works fine when I connect from Xen 3.0.2 to Xen 3.0.2

But it fails with parsing the response when I connect from Xen 3.0.3 to Xen 3.0.3.
The request sent seems similar. The server is does not seem to be writing the XML response header (or is getting lost). Seems like a bug. Has anything changed in this area?

Please see attached files.
Thanks
/Jd




---------------------------------
Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.
Re: XMLRPC behavior changed? [ In reply to ]
On Tue, Nov 14, 2006 at 04:43:52PM -0800, jdsw wrote:

> Hi
> I am trying to connect to a remote XEN daemon using SSH tunnel
> (written using paramiko) . The servers have xend-tcp-xml-rpc-server is
> enabled. It works fine when I connect from Xen 3.0.2 to Xen 3.0.2
>
> But it fails with parsing the response when I connect from Xen 3.0.3 to
> Xen 3.0.3.
> The request sent seems similar. The server is does not seem to be writing
> the XML response header (or is getting lost). Seems like a bug. Has
> anything changed in this area?

Lots of things have changed above this, but little has changed at the problem
layer, as far as I can tell. We still intend to preserve the old protocol, so
this is a bug.

> ===================
> send: 'POST /RPC2 HTTP/1.0\r\nHost: 192.168.12.102:8005\r\nUser-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: text/xml\r\nContent-Length: 151\r\n\r\n'
> send: "<?xml version='1.0'?>\n<methodCall>\n<methodName>xend.domains</methodName>\n<params>\n<param>\n<value><int>1</int></value>\n</param>\n</params>\n</methodCall>\n"
> ==================
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Server: BaseHTTP/0.3 Python/2.4.3
> header: Date: Tue, 14 Nov 2006 17:17:30 GMT
> header: Content-Type: text/xml
> header: Content-Length: 17015
> body: '<string>domid</string></value>\n<value><int>51</int></value>\n</data></array></value>\n<value><array><data>\n<value><string>uuid</string></value>\n<value><string>d61f62d9-2f77-e6a1-8bef-3f2e36abf4e5</string></value>\n</data></array></value>\n<value><array><data>\n<value><string>vcpus</string></value>\n<value><int>1</int></value>\n</data></array></value>\n<value><array><data>\n<value><string>cpu_weight</string></value>\n<value><double>1.0</double></value>\n</data></array></value>\n<value><array><data>\n<value><string>memory</string></value>\n<value><int>256</int></value>\n</data></array></value>\n<value><array><data>\n<value><string>shadow_memory</string></value>\n<value><int>0</int></value>\n</data></array></value>\n<value><array><data>\n<value><string>maxmem</string></value>\n<value><int>256</int></value>\n</data></array></value>\n<value><array><data>\n<value><string>features</string></value>\n<value><string></string></value>\n</data></array></value>\n<value><array><data>\n<value><string>name</string> ></value>\n<value><string>T1</string></va'
> got expat error not well-formed (invalid token): line 1, column 23

It looks like you've lost the first block of the body of the response, though
you've got the HTTP header, so the connection itself is OK. Could you add
some tracing into xen.util.xmlrpclib2 (_marshaled_dispatch seems the right
place) and see where it is losing that data?

Cheers,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel