xmlrpc: problems with socket handling, close, shutdown of server,TIME_WAIT, ...

[thomas.lehmann.private]

Hi,

taking the xml-rpc derived from standard example is working - basically - but with following scenario I do not understand the problem. Maybe you can help:

- one Unittest that does create the xmlrpc server in a thread
in "setUp" and shutdown of it in tearDown.
The xml-rcp server does store/load a value for a key.
(It's for testing/learning purpose)

Problem(s):

- If I run the test method twice (copy and paste and rename)
then I get a "error: [Errno 98] Address already in use"
(I assumend the tearDown would have closed all sockets)

- Because of this I removed that second method and so it's fine
but checking with "netstat -n | grep <port>" I see as many
sockets in TIME_WAIT as I did xml-rpc calls. Also that python
test is not running anymore it take some time until those
entries vanish from the netstat list.

Question(s):

I assumed that calling the shutdown of the server (in tearDown)
does close all sockets. The SimpleXMLRPCServer is derived from
SocketServer.TCPServer and those one is derived from BaseServer.
Those has the shutdown which is documented to stop the serve_forever loop.
Is this correct or do I have to shutdown in another way?

At client side I'm using the ServerProxy. It does obviously not
have a "close". From code it looks like that I could do something
like "proxy("close")()" but that looks somehow wired?
Can I close a proxy?, should I?, ... what is the way?

 

[dieter]

...
taking the xml-rpc derived from standard example is working - basically - but with following scenario I do not understand the problem. Maybe you can help:

- one Unittest that does create the xmlrpc server in a thread
in "setUp" and shutdown of it in tearDown.
The xml-rcp server does store/load a value for a key.
(It's for testing/learning purpose)

Problem(s):

- If I run the test method twice (copy and paste and rename)
then I get a "error: [Errno 98] Address already in use"
(I assumend the tearDown would have closed all sockets)

For reliability reasons (their might be (communication) packets under way
that may arrive at the wrong partner), a port stays "in use"
for twice (I think) the maximal packet lifetime after its "shutdown".
This is a TCP (not a Python) property.
There is a TCP(socket) option to supress this.

For the details, consult the TCP specification.