9:15 p.m.
On Thu, 2012-03-15 at 10:34 +0100, Chris Kühl wrote:
On Wed, Mar 14, 2012 at 2:26 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> More specifically, consider the following sequence of events:
> 1. files are modified and the quiesence timeout is started
> 2. a client connects, starts a session and syncs
> 3. the timeout triggers, causing the server to shut down
>
> If it works as designed (we don't have tests for it, do we?), then the
> syncevo-dbus-helper will continue to run and complete the session. But
> the client will see an unexpected server disconnect and won't be able to
> monitor progress of the still running session, because the running
> helper isn't connected to any syncevo-dbus-server instance.
>
> It could even be worse: with bad timing, an obsolete syncevo-dbus-helper
> might get started which then fails because it doesn't match the
> installed files.
>
> IMHO adding any kind of resource should be prevented while the
> m_shutdownRequested flag is set. Returning an error message to the
> client would be okay
Yes, and this is how it should work.
I've added a test (which failed before fixing the rewritten server),
then changed the server accordingly. Code is in concurrent-sync-pohly
branch:
commit dd6af8a673292cf336715913e84fc8eed6f14f70
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Mar 14 14:29:49 2012 +0100
D-Bus testing: server should not allow new sessions while shutting down
The old implementation queued session requests, but then ran its own
high-priority shutdown session instead as soon as possible. A client
then loose the connection to the server instead of getting its pending
session activated.
The fork/exec server rewrite initially allowed the session to run,
instead of shutting down. The goal is to reject session requests while
shutting down.
commit b2ae0864167a9936f0826ae0463eed4fb6b08cdf
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Thu Mar 15 09:44:07 2012 +0100
D-Bus server: prevent new sessions and connections when shutting down
When syncevo-dbus-server is preparing to shut down, it should not
allow new resources (sessions and connections) to register
themselves (because they are not meant to run) and should not run
them (happened inside addResource()).
This is achieved by throwing a "server shutting down" exception in the
D-Bus API implementation (to avoid the entire resource creation early)
and in the addSource() implementation (to catch resource where
creation was already kicked of before shutdown started).
However, throwing exections in addSource() currently kill
syncevo-dbus-server. That needs to be fixed, see "[SyncEvolution]
GDBus C++ add_filter + fork/exec dbus-server".
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.