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

[mikhail.zabaluev at nokia.com]

Hi,

> -----Original Message-----
> From: eopage at gmail.com [mailto:eopage at gmail.com] On Behalf Of ext
> Edward Page
> Sent: Saturday, March 13, 2010 6:51 PM
> To: Zabaluev Mikhail (Nokia-D/Helsinki)
> Cc: sjoerd at luon.net; telepathy at lists.freedesktop.org
> Subject: Re: [Telepathy] Best way to handle the client leaking
> connections?
> 
> 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.

Yes, it was a problem with our implementation: blocking on disconnection meant that a RequestConnection call to reestablish the connection timed out. Even if blocking is resolved, making an object linger in disconnecting state will keep the DBus object path occupied, so if the connection object paths are not randomized, this will result in a conflict if the connection is restarted.

> 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.

Well, as a general rule, a D-Bus service should not block for potentially long periods of time while handling method calls. By extension, it means that the service's event loop processing DBus messages should not have such blockers at all. There is no good alternative to being async.

> 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).

For one thing, I think Mission Control should keep watch on lingering connections even after it has ceased doing anything useful with them, and react to the connection status signals. If the connection comes online after all, it could be treated positively, or it could be immediately told to disconnect just to not muddle the MC state too much. A bug on bugs.freedesktop.org could be filed.
But the case of a RequestConnection timeout is worse: you don't get a connection object to watch, and DBus will not route your call result back even if the CM ultimately responds. Life is tough for misbehaving services.

Best regards,
  Mikhail