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 do not claim there is a bug, I am simply pointing
out that when using oprofile to profile the test application, most of
the time is spent in a specific routine.  Now it could be a side
affect of xmlrpc, I don't know - I do not claim to be a "programmer".

I am looking to turn on verbose mode in xmlrpc.  As soon as I do that
I will test again and send the results.

On Jan 15, 2008 7:05 PM, Fredrik Lundh <[email protected]> wrote:
>
> 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 run *all* Python programs, so I think
> we'd noticed if it had a tendency to hang unexpectedly...
>
>
> __________________________________
> Tracker <[email protected]>
> <http://bugs.python.org/issue1327>
> __________________________________
>