Skip Montanaro [EMAIL PROTECTED] added the comment:
Can this ticket be closed? I've still yet to see anything here that
anyone could actually do anything with.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1327
__
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Requested info not available, closing this ticket.
--
resolution: - works for me
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1327
Eric Sammons added the comment:
Here is the header information that I get:
snip
reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Tue, 22 Jan 2008 14:42:54 GMT
header: Server: Apache
header: Content-Length: 183
header: Content-Type: text/xml;charset=UTF-8
/snip
Then I get addition send followed by
Eric Sammons added the comment:
Some strace data:
WORKS:
Python 2.3.4 (#1, Jan 9 2007, 16:40:09)
strace -cf ./test.py /tmp/out
Process 9439 detached
% time seconds usecs/call callserrors syscall
-- --- --- - -
33.10
Amaury Forgeot d'Arc added the comment:
Please, could you use the python profiler instead? Since most of the
time is spent in the bytecode interpreter, the results are much more
meaningful.
Something like:
#!/usr/bin/env python
import xmlrpclib
import profile
u = 'someuser'
p = 'password'
Eric Sammons added the comment:
Has anybody else tested this against an RPC server that has more than
300 items to be returned. I find it interesting that before all the
xmlrpc code changed everything works fine, but after the code change
(re-write) things don't seem to work.
As for the bug, I
Eric Sammons added the comment:
I have added the verbose=1 option, the processing hangs in the body: where :
code
for a in l:
print a['channel_label']
/code
Is returning the data. Initially it returns data quickly and then slows
until it eventually stops.
Here is the sample of the body
Changes by Christian Heimes:
--
priority: - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1327
__
___
Python-bugs-list mailing list
Unsubscribe:
Fredrik Lundh added the comment:
Can you switch on verbose mode in xmlrpclib, so you can see *where* the
transfer hangs?
Arguing that a hanging Python program must be caused by a bug in the
code that *executes* the Python program isn't that meaningful, really.
After all, that code is used to
Eric Sammons added the comment:
Please find the attached ceval.c. This file was generated from oprofile
and gives clear indicators where the simple program below gets hung up.
You will find in the oprofile output, from ceval.c, that PyEval_Frame
has a total of 1649 26.2789. This indicates
Amaury Forgeot d'Arc added the comment:
I don't think ceval is the issue here.
the code has changed a great deal with regards to xmlrpc
I am not sure to understand what you mean: xmlrpc is mostly written in
python code.
ceval.c is the place where the interpreter executes python code.
Fredrik Lundh added the comment:
That changes to ceval should have introduced some kind of XML-RPC
package limit seems a bit unlikely. If you can still reproduce this,
can you try instrumenting the xmlrpclib.py library to see where it gets
stuck?
(passing in verbose=True to the Server[Proxy]
Eric Sammons added the comment:
I have tested 2.4.4 and 2.5.1 from python.org and both suffer from the
exact same issue. I have also compared ceval.c from 2.3, the last known
working copy and ceval.c from 2.4+ and found that ceval.c has undergone
some pretty significant changes.
13 matches
Mail list logo
