Re: xmlrpclib hangs execution
Hi, > 2. The Python implementation ofxmlrpcis not very robust. It just waits for > the connection to close. A well-written client (like your Java client) > would detect the presence of a Content-Length header and use that. I'm facing a similar ordeal here. I think the right thing to do would be to adjust the xmlrpc library to parse the header and check for the Content-Length. Right now, the socket seems to read 1024 bytes, so naturally, when the connection closes, the socket throws an error, because it thinks that more bytes are coming. Which sounds rather weird to me, given the fact that in rare cases the reply will be a multiple of 1024 bytes :-) -- Andy Georges -- http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpclib hangs execution
On Jun 14, 3:10 pm, [EMAIL PROTECTED] wrote:
> Hi,
>
> > 2. The Python implementation ofxmlrpcis not very robust. It just waits for
> > the connection to close. A well-written client (like your Java client)
> > would detect the presence of a Content-Length header and use that.
>
> I'm facing a similar ordeal here. I think the right thing to do would
> be to adjust the xmlrpc library to parse the header and check for the
> Content-Length. Right now, the socket seems to read 1024 bytes, so
> naturally, when the connection closes, the socket throws an error,
> because it thinks that more bytes are coming. Which sounds rather
> weird to me, given the fact that in rare cases the reply will be a
> multiple of 1024 bytes :-)
>
> -- Andy Georges
For now, these changes helped me out. It probably (read: certainly)
needs some cleanup, and I'm probably not taking everything into
account as I should:
--- xmlrpclib.py2007-06-14 15:42:36.0 +0200
+++ /sw/lib/python2.5/xmlrpclib.py 2006-11-29 02:46:38.0
+0100
@@ -1184,11 +1184,6 @@
errcode, errmsg, headers = h.getreply()
-expected_payload_length = 1024
-if headers.has_key('content-length'):
- expected_payload_length = int(headers['content-length'])
-
-
if errcode != 200:
raise ProtocolError(
host + handler,
@@ -1203,7 +1198,7 @@
except AttributeError:
sock = None
-return self._parse_response(h.getfile(), sock,
expected_payload_length)
+return self._parse_response(h.getfile(), sock)
##
# Create parser.
@@ -1323,23 +1318,21 @@
#could not be accessed).
# @return Response tuple and target method.
-def _parse_response(self, file, sock, size=1024):
+def _parse_response(self, file, sock):
# read response from input file/socket, and parse it
p, u = self.getparser()
while 1:
if sock:
-response = sock.recv(size)
+response = sock.recv(1024)
else:
-response = file.read(size)
+response = file.read(1024)
if not response:
break
if self.verbose:
print "body:", repr(response)
p.feed(response)
-if len(response) == size:
-break
file.close()
p.close()
-- Andy Georges
--
http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpclib hangs execution
I think a better fix than the one I posted below is using the HTTPConnection library, as opposed to the HTTP library from httplib. A patch can be found below: --- /sw/lib/python2.5/xmlrpclib.py 2006-11-29 02:46:38.0 +0100 +++ xmlrpclib.py2007-06-15 16:03:17.0 +0200 @@ -1182,23 +1182,13 @@ self.send_user_agent(h) self.send_content(h, request_body) -errcode, errmsg, headers = h.getreply() +response = h.getresponse() + +if response.status != 200: + raise ProtocolError(host + handler, response.status, response.reason, response.msg.headers) -if errcode != 200: -raise ProtocolError( -host + handler, -errcode, errmsg, -headers -) - -self.verbose = verbose - -try: -sock = h._conn.sock -except AttributeError: -sock = None - -return self._parse_response(h.getfile(), sock) +payload = response.read() +return payload ## # Create parser. @@ -1250,7 +1240,7 @@ # create a HTTP connection object from a host descriptor import httplib host, extra_headers, x509 = self.get_host_info(host) -return httplib.HTTP(host) +return httplib.HTTPConnection(host) -- http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpclib hangs execution
Arno,
> Your patches solves the problem too. Thanks!
>
> One thing: if I use the unpatched xmlrpclib.py, the printed output of
> xml calls look like:
>
> {'state': 0, 'str': 'Info_RT'}
>
> But if I use your patch, they look like:
>
> state0strInfo_RT
>
> I prefer the former, as it is easier to extract the info. Why did this
> change with your patch?
I've no idea, I'll look into this as soon as possible. Thanks for
letting me know.
I want to point you to another possible solution, which is using a
derived
transport class. I've posted this on my blog, see
http://www.itkovian.net/base/transport-class-pythons-xml-rpc-lib
I'm not sure if this might solve the problem you pointed out.
-- Andy
--
http://mail.python.org/mailman/listinfo/python-list
