python xmlrpc: cannot handle connection errors

[xristoph at googlemail.com]

Hello everyone!

I am trying to set up a broker-worker system (one broker, multiple and
heterogeneous workers) in python for a local network (though possibly
also over inet). I am using SimpleXMLRPCServer and
xmlrpclib.ServerProxy for connections.

Whatever I do, after about 100,000 to 150,000 XMLRPCalls over a single
ServerProxy connection, I am getting a connection error (usually
"connection reset by peer"). I have tried deleting the ServerProxy,
setting up a new one and calling the function again when the error
occurs, but this does not change anything:

# this is the worker's secureRPC; the broker's works analogously
def worker_secureRPC(self, fname, args=None):
		tries = 2             # raising the nr of tries does not change
anything
		retval = None
                for i in range(0,tries):
			try:
				fref = self.getfref(fname)
                                # returns a reference to
self.sender.fname
				if (args==None):
					retval = fref()
				else:
					retval = fref(*args)
                                except:
				self.sender = None
				time.sleep(1)
				self.sender = ServerProxy("http://" + self.brokerHost + ":" +
str(self.brokerPort))
				if (i>=(tries-1)):
					raise


Then, thinking that maybe the "return" statement produces the error, I
tried doing error handling there as well (keep in mind that the
function might have been called already, so don't do the same action
twice):

	def worker_foo(self, popcontainer, failed=[]):
		self.lock.acquire()
		if (len(failed) > 0):
			while (len(failed) > 0):
				failed.pop()
		else:
                        do_stuff_in_new_thread()
		self.lock.release()
		try:
			return True
		except:
			failed.append("failed")

The function foo gets called remotely after the set-up of the new
ServerProxy, but does produce the same error again! (socket.error:
connection reset by peer). Btw, another function sends the result back
to the Broker again via xmlrpc, resulting in asynchronous
communication, so we only need to return some bogus value here.

Am I missing sth obvious here, or why can I not re-build the
connection? What can I do to handle this error correctly?

cheers,

Christoph