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

[Edward Page]

On Mon, Mar 15, 2010 at 9:07 AM,  <mikhail.zabaluev at nokia.com> wrote:
> 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.

Is it a best practice to randomize the paths?  Telepathy-python
provides a default implementation for building the path and doesn't
randomize it.  If it is a best practice then I'll send a bug over
their way.

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

Now filed
https://bugs.freedesktop.org/show_bug.cgi?id=27101

I saw a comment somewhere about not blocking and was hoping it
wouldn't be an issue but I can see why it is.  I guess I'll go clean
it up.

Thanks for the pointers though in helping identify why it was misbehaving.

Ed Page