[Telepathy] Best way to handle the client leaking connections?

[Edward Page]

On Wed, Mar 10, 2010 at 7:14 AM,  <mikhail.zabaluev at nokia.com> wrote:
> To make Mission Control happy, a connection manager should not block its internal event loop which processes D-Bus method calls, at least at the time when RequestConnection is called. If the RequestConnection D-Bus call times out, Mission control will consider the connection failed, and rightly so.
> So, if you have any such kind of snags in your protocol stack, you ought to work around them. Look closely at any blocking calls performed: 1) at connect time; 2) at connection shutdown so they may leave a connection object lingering. Consider using asynchronous implementation for such functionality if available, or put it to a thread.

Originally I had issues with blocking calls in Connection.Connect.
Since then I've moved the content of my Connection.Connect call to an
idle callback so Connect returns immediately.  I've checked
RequestConnection, Connect, and Disconnect.  I should not be blocking.

Looking closer I found a couple more issues in my CM.  I'm hoping
working around them will reduce the average case for CM response time
to RequestConnection/Connect/Disconnect that the user will rare see an
issue.

Despite my claim that I don't block in Disconnect, somehow my
Disconnect took 6 seconds according to one log file.  I'm unsure why
but this can have a negative impact.

My CM shuts down when idle.  The countdown starts at the beginning of
my Disconnect which if my Disconnect blocks means it will close
immediately.  That with python's startup time means that if the
RequestConnect is what causes DBus to restart my CM then it could have
have taken a while.

Though if a CM ever blocks the event loop and a Disconnect comes in
(or RequestConnect/Connect for another account) then it can't be
processed until the blocking call gets back.  So we get blocking by
side-effect.

I can understand the need for the timeout, if something happened to
the CM like its hung or crashed then you don't want to wait on it
forever.  It just seems kind of sad that I have the leisure of running
asynchronously and yet I have add an extras layer of asynchronous
calls.

It also seems worrisome that you give up on a CM without ever
notifying it that you gave up.   I can understand that in an ideal
situation no CM would ever hit this issue but its still good to be
defensive, especially when it can impact the user experience (can't
reconnect) and battery life (connection got left open with any of its
keep-alives firing).

Thanks for all the help provided, its been a big benefit to my users
Ed Page