Why your xml-rpc routines need fault tolerance

Just an FYI for those of you who are working with xml-rpc. Do not just assume that your operations will work all the time. If your applications don't handle failures gracefully, odd and (usually) bad things can happen.


From one of my cron jobs today:

Warning: fsockopen(): unable to connect to xmlrpc.secondlife.com:80 in /xxx/xxx/xxx/xxx/xmlrpc.php on line 357

Warning: fsockopen(): unable to connect to xmlrpc.secondlife.com:80 in /xxx/xxx/xxx/xxx/xmlrpc.php on line 357

Warning: fsockopen(): unable to connect to xmlrpc.secondlife.com:80 in /xxx/xxx/xxx/xxx/xmlrpc.php on line 357


Here you can see one of my two layers of fault-tolerance. The low-level layer is just "try three times then fail". The higher level will retry every so often for X amount of time (this is not an interactive process, so transactions do not have to take place in real-time) and after X expires, will remove the object from the queue.

How do you handle fault tolerance with your xml-rpc communications?

I don't.... I've never really experienced those problems before... that's odd.

The errors above were undoubtedly because my server attempted communications during the update today.

It's not odd. It's inevitable.

You always have to assume that the XML server may become unreachable at some point, and code in safeties. It's the only way to code.

Indeed. We will sometimes turn the XML-RPC server off during updates to reduce log noise during the update and then turn it back on after the update is complete.

Checking to see if you actually succeed is generally good practice, though, when talking to a network server of any type; you never know when it's going to go away.

And besides, sometimes I shut it down just to screw with you.

M, channeling Andrew's power trip with Kick All.

LOL! Somebody give this man a raise