[Telepathy] Best way to handle the client leaking connections?
eopage at byu.net
Mon Mar 15 19:34:20 PDT 2010
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
> 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.
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
Thanks for the pointers though in helping identify why it was misbehaving.
More information about the telepathy