syncevolution/src/dbus/server/auto-sync-manager.cpp

523 lines
21 KiB
C++
Raw Normal View History

/*
* Copyright (C) 2011 Intel Corporation
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) version 3.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301 USA
*/
#include "auto-sync-manager.h"
#include "session.h"
#include "server.h"
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
#include "dbus-callbacks.h"
#include "presence-status.h"
#include <glib.h>
#include <glib/gi18n.h>
#include <boost/tokenizer.hpp>
SE_BEGIN_CXX
AutoSyncManager::AutoSyncManager(Server &server) :
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
m_server(server),
m_autoTermLocked(false)
{
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
static void updatePresence(Timespec *t, bool present)
{
*t = present ?
Timespec::monotonic() :
Timespec();
}
boost::shared_ptr<AutoSyncManager> AutoSyncManager::createAutoSyncManager(Server &server)
{
boost::shared_ptr<AutoSyncManager> result(new AutoSyncManager(server));
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
result->m_me = result;
result->init();
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// update cached information about a config each time it changes
server.m_configChangedSignal.connect(Server::ConfigChangedSignal_t::slot_type(&AutoSyncManager::initConfig, result.get(), _1).track(result));
// monitor running sessions
server.m_newSyncSessionSignal.connect(Server::NewSyncSessionSignal_t::slot_type(&AutoSyncManager::sessionStarted, result.get(), _1).track(result));
// Keep track of the time when a transport became online. As with
// time of last sync, we are pessimistic here and assume that the
// transport just now became available.
PresenceStatus &p = server.getPresenceStatus();
Timespec now = Timespec::monotonic();
if (p.getBtPresence()) {
result->m_btStartTime = now;
}
p.m_btPresenceSignal.connect(PresenceStatus::PresenceSignal_t::slot_type(updatePresence,
&result->m_btStartTime,
_1).track(result));
if (p.getHttpPresence()) {
result->m_httpStartTime = now;
}
p.m_httpPresenceSignal.connect(PresenceStatus::PresenceSignal_t::slot_type(updatePresence,
&result->m_httpStartTime,
_1).track(result));
return result;
}
void AutoSyncManager::init()
{
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
m_notificationManager = NotificationManagerFactory::createManager();
m_notificationManager->init();
m_peerMap.clear();
SyncConfig::ConfigList list = SyncConfig::getConfigs();
BOOST_FOREACH(const SyncConfig::ConfigList::value_type &server, list) {
initConfig(server.first);
}
}
void AutoSyncManager::initConfig(const std::string &configName)
{
SE_LOG_DEBUG(NULL, "auto sync: updating info about config %s", configName.c_str());
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (configName.empty()) {
// Anything might have changed. Check all configs we know
// about (might have been removed) and all existing configs
// (might have been modified).
std::set<std::string> configs;
BOOST_FOREACH (const PeerMap::value_type &entry, m_peerMap) {
const std::string &configName = entry.first;
configs.insert(configName);
}
BOOST_FOREACH (const StringPair &entry, SyncConfig::getConfigs()) {
const std::string &configName = entry.first;
configs.insert(configName);
}
BOOST_FOREACH (const std::string &configName, configs) {
if (!configName.empty()) {
initConfig(configName);
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// TODO: only call schedule() once in this case, instead
// once per recursive initConfig().
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// TODO: once we depend on shared settings, remember to check
// all other configs which share the same set of settings.
// Not currently the case.
// Create anew or update, directly in map. Never remove
// old entries, because we want to keep the m_lastSyncTime
// in cases where configs get removed and recreated.
boost::shared_ptr<AutoSyncTask> &task = m_peerMap[configName];
if (!task) {
task.reset(new AutoSyncTask(configName));
// We should check past sessions here. Instead we assume
// the "worst" case, which is that the session ran zero
// seconds ago. This has the additional benefit that we
// don't run automatic sync sessions directly after
// starting up (the system or syncevo-dbus-server).
task->m_lastSyncTime = Timespec::monotonic();
}
SyncConfig config (configName);
if (config.exists()) {
std::vector<std::string> urls = config.getSyncURL();
std::string autoSync = config.getAutoSync();
//enable http and bt?
bool http = false, bt = false;
bool any = false;
if (autoSync.empty() ||
boost::iequals(autoSync, "0") ||
boost::iequals(autoSync, "f")) {
http = false;
bt = false;
any = false;
} else if (boost::iequals(autoSync, "1") ||
boost::iequals(autoSync, "t")) {
http = true;
bt = true;
any = true;
} else {
BOOST_FOREACH(std::string op,
boost::tokenizer< boost::char_separator<char> >(autoSync,
boost::char_separator<char>(","))) {
if(boost::iequals(op, "http")) {
http = true;
} else if(boost::iequals(op, "obex-bt")) {
bt = true;
}
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
task->m_peerName = config.getPeerName();
if (task->m_peerName.empty()) {
task->m_peerName = configName;
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
task->m_interval = config.getAutoSyncInterval();
task->m_delay = config.getAutoSyncDelay();
task->m_remoteDeviceId = config.getRemoteDevID();
task->m_notifyLevel = config.getNotifyLevel();
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// Assume that whatever change was made might have resolved
// the past problem -> allow auto syncing again.
task->m_permanentFailure = false;
SE_LOG_DEBUG(NULL,
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
"auto sync: %s: auto sync '%s', %s, %s, %d seconds repeat interval, %d seconds online delay",
configName.c_str(),
autoSync.c_str(),
bt ? "Bluetooth" : "no Bluetooth",
http ? "HTTP" : "no HTTP",
task->m_interval, task->m_delay);
task->m_urls.clear();
BOOST_FOREACH(std::string url, urls) {
AutoSyncTask::Transport transport = AutoSyncTask::NEEDS_OTHER; // fallback for unknown sync URL
if (boost::istarts_with(url, "http")) {
transport = AutoSyncTask::NEEDS_HTTP;
} else if (boost::istarts_with(url, "local")) {
// TODO: instead of assuming that local sync needs HTTP, really look into the target config
// and determine what the peerType is
transport = AutoSyncTask::NEEDS_HTTP;
} else if (boost::istarts_with(url, "obex-bt")) {
transport = AutoSyncTask::NEEDS_BT;
}
if((transport == AutoSyncTask::NEEDS_HTTP && http) ||
(transport == AutoSyncTask::NEEDS_BT && bt) ||
(transport == AutoSyncTask::NEEDS_OTHER && any)) {
task->m_urls.push_back(std::make_pair(transport, url));
SE_LOG_DEBUG(NULL,
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
"auto sync: adding config %s url %s",
configName.c_str(),
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
url.c_str());
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
} else {
// Just clear urls, which disables auto syncing.
task->m_urls.clear();
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
bool lock = preventTerm();
if (m_autoTermLocked && !lock) {
SE_LOG_DEBUG(NULL, "auto sync: allow auto shutdown");
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
m_server.autoTermUnref();
m_autoTermLocked = false;
} else if (!m_autoTermLocked && lock) {
SE_LOG_DEBUG(NULL, "auto sync: prevent auto shutdown");
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
m_server.autoTermRef();
m_autoTermLocked = true;
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// reschedule
schedule("initConfig() for " + configName);
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
void AutoSyncManager::schedule(const std::string &reason)
{
SE_LOG_DEBUG(NULL, "auto sync: reschedule, %s", reason.c_str());
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// idle callback will be (re)set if needed
m_idleConnection.disconnect();
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (!preventTerm()) {
SE_LOG_DEBUG(NULL, "auto sync: nothing to do");
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
return;
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (!m_server.isIdle()) {
// Only schedule automatic syncs when nothing else is
// going on or pending.
SE_LOG_DEBUG(NULL, "auto sync: server not idle");
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
connectIdle();
return;
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// Now look for a suitable task that is ready to run.
Timespec now = Timespec::monotonic();
BOOST_FOREACH (const PeerMap::value_type &entry, m_peerMap) {
const std::string &configName = entry.first;
const boost::shared_ptr<AutoSyncTask> &task = entry.second;
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (task->m_interval <= 0 || // not enabled
task->m_permanentFailure) { // don't try again
continue;
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (task->m_lastSyncTime + task->m_interval > now) {
// Ran too recently, check again in the future. Always
// reset timer, because both m_lastSyncTime and m_interval
// may have changed.
//
// Adds two seconds just to be on the safe side and not
// wake up again too soon.
int seconds = (task->m_lastSyncTime + task->m_interval - now).seconds() + 2;
SE_LOG_DEBUG(NULL, "auto sync: %s: interval expires in %ds",
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
configName.c_str(),
seconds);
task->m_intervalTimeout.runOnce(seconds,
boost::bind(&AutoSyncManager::schedule,
this,
configName + " interval timer"));
continue;
}
std::string readyURL;
BOOST_FOREACH (const AutoSyncTask::URLInfo_t::value_type &urlinfo, task->m_urls) {
// check m_delay against presence of transport
Timespec *starttime = NULL;
PresenceStatus::PresenceSignal_t *signal = NULL;
Timeout *timeout = NULL;
switch (urlinfo.first) {
case AutoSyncTask::NEEDS_HTTP:
SE_LOG_DEBUG(NULL, "auto sync: %s: %s uses HTTP",
configName.c_str(),
urlinfo.second.c_str());
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
starttime = &m_httpStartTime;
signal = &m_server.getPresenceStatus().m_httpPresenceSignal;
timeout = &task->m_httpTimeout;
break;
case AutoSyncTask::NEEDS_BT:
SE_LOG_DEBUG(NULL, "auto sync: %s: %s uses Bluetooth",
configName.c_str(),
urlinfo.second.c_str());
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
starttime = &m_btStartTime;
signal = &m_server.getPresenceStatus().m_btPresenceSignal;
timeout = &task->m_btTimeout;
break;
case AutoSyncTask::NEEDS_OTHER:
SE_LOG_DEBUG(NULL, "auto sync: %s: %s uses some unknown transport",
configName.c_str(),
urlinfo.second.c_str());
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
break;
}
if (!starttime || // some other transport, assumed to be online, use it
(*starttime && // present
(task->m_delay <= 0 || *starttime + task->m_delay <= now))) { // present long enough
SE_LOG_DEBUG(NULL, "auto sync: %s: ready to run via %s (transport present for %lds > %ds auto sync delay)",
configName.c_str(),
urlinfo.second.c_str(),
starttime ? (long)(*starttime - now).seconds() : -1,
task->m_delay);
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
readyURL = urlinfo.second;
break;
}
if (!*starttime) {
// check again when it becomes present
signal->connect(PresenceStatus::PresenceSignal_t::slot_type(&AutoSyncManager::schedule,
this,
"presence change").track(m_me));
SE_LOG_DEBUG(NULL, "auto sync: %s: transport for %s not present",
configName.c_str(),
urlinfo.second.c_str());
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
} else {
// check again after waiting the requested amount of time
int seconds = (*starttime + task->m_delay - now).seconds() + 2;
SE_LOG_DEBUG(NULL, "auto sync: %s: presence delay of transport for %s expires in %ds",
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
configName.c_str(),
urlinfo.second.c_str(),
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
seconds);
timeout->runOnce(seconds,
boost::bind(&AutoSyncManager::schedule,
this,
configName + " transport timer"));
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (!readyURL.empty()) {
// Found a task, run it. The session is not attached to any client,
// but we keep a pointer to it, so it won't go away.
// m_task = task;
// Just in case... also done in syncDone() when we detect
// that session is completed.
m_server.delaySessionDestruction(m_session);
task->m_syncSuccessStart = false;
m_session = Session::createSession(m_server,
task->m_remoteDeviceId,
configName,
m_server.getNextSession());
// Temporarily set sync URL to the one which we picked above
// once the session is active (setConfig() not allowed earlier).
ReadOperations::Config_t config;
config[""]["syncURL"] = readyURL;
m_session->m_sessionActiveSignal.connect(boost::bind(&Session::setConfig,
m_session.get(),
true, true,
config));
// Run sync as soon as it is active.
m_session->m_sessionActiveSignal.connect(boost::bind(&Session::sync,
m_session.get(),
"",
SessionCommon::SourceModes_t()));
// Now run it.
m_session->activate();
m_server.enqueue(m_session);
// Reschedule when server is idle again.
connectIdle();
return;
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
SE_LOG_DEBUG(NULL, "auto sync: nothing to do now");
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
void AutoSyncManager::connectIdle()
{
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
m_idleConnection =
m_server.m_idleSignal.connect(Server::IdleSignal_t::slot_type(&AutoSyncManager::schedule,
this,
"server is idle").track(m_me));
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
void AutoSyncManager::sessionStarted(const boost::shared_ptr<Session> &session)
{
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// Do we have a task for this config?
std::string configName = session->getConfigName();
PeerMap::iterator it = m_peerMap.find(configName);
if (it == m_peerMap.end()) {
SE_LOG_DEBUG(NULL, "auto sync: ignore running sync %s without config",
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
configName.c_str());
return;
}
boost::shared_ptr<AutoSyncManager> me = m_me.lock();
if (!me) {
SE_LOG_DEBUG(NULL, "auto sync: already destructing, ignore new sync %s",
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
configName.c_str());
return;
}
const boost::shared_ptr<AutoSyncTask> &task = it->second;
task->m_lastSyncTime = Timespec::monotonic();
// track permanent failure
session->m_doneSignal.connect(Session::DoneSignal_t::slot_type(&AutoSyncManager::anySyncDone, this, task.get(), _1).track(task).track(me));
if (m_session == session) {
// Only for our own auto sync session: notify user once session starts successful.
//
// In the (unlikely) case that the AutoSyncTask gets deleted, the
// slot won't get involved, thus skipping user notifications.
// Also protects against manager destructing before session.
session->m_syncSuccessStartSignal.connect(Session::SyncSuccessStartSignal_t::slot_type(&AutoSyncManager::autoSyncSuccessStart, this, task.get()).track(task).track(me));
// Notify user once session ends, with or without failure.
// Same instance tracking as for sync success start.
session->m_doneSignal.connect(Session::DoneSignal_t::slot_type(&AutoSyncManager::autoSyncDone, this, task.get(), _1).track(task).track(me));
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
bool AutoSyncManager::preventTerm()
{
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
BOOST_FOREACH (const PeerMap::value_type &entry, m_peerMap) {
const boost::shared_ptr<AutoSyncTask> &task = entry.second;
if (task->m_interval > 0 &&
!task->m_permanentFailure &&
!task->m_urls.empty()) {
// that task might run
return true;
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
return false;
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
void AutoSyncManager::autoSyncSuccessStart(AutoSyncTask *task)
{
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
task->m_syncSuccessStart = true;
SE_LOG_INFO(NULL,"Automatic sync for '%s' has been successfully started.\n",
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
task->m_peerName.c_str());
if (m_server.notificationsEnabled() &&
task->m_notifyLevel >= SyncConfig::NOTIFY_ALL) {
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
std::string summary = StringPrintf(_("%s is syncing"), task->m_peerName.c_str());
std::string body = StringPrintf(_("We have just started to sync your computer with the %s sync service."),
task->m_peerName.c_str());
// TODO: set config information for 'sync-ui'
m_notificationManager->publish(summary, body);
}
}
/**
* True if the error is likely to go away by itself when continuing
* with auto-syncing. This errs on the side of showing notifications
* too often rather than not often enough.
*/
static bool ErrorIsTemporary(SyncMLStatus status)
{
switch (status) {
case STATUS_TRANSPORT_FAILURE:
return true;
default:
// pretty much everying this not temporary
return false;
}
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
void AutoSyncManager::autoSyncDone(AutoSyncTask *task, SyncMLStatus status)
{
SE_LOG_INFO(NULL,"Automatic sync for '%s' has been done.\n", task->m_peerName.c_str());
if (m_server.notificationsEnabled()) {
// send a notification to notification server
std::string summary, body;
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
if (task->m_syncSuccessStart && status == STATUS_OK) {
if (task->m_notifyLevel >= SyncConfig::NOTIFY_ALL) {
// if sync is successfully started and done
summary = StringPrintf(_("%s sync complete"), task->m_peerName.c_str());
body = StringPrintf(_("We have just finished syncing your computer with the %s sync service."),
task->m_peerName.c_str());
//TODO: set config information for 'sync-ui'
m_notificationManager->publish(summary, body);
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
} else if (task->m_syncSuccessStart || !ErrorIsTemporary(status)) {
if (task->m_notifyLevel >= SyncConfig::NOTIFY_ERROR) {
// if sync is successfully started and has errors, or not started successful with a permanent error
// that needs attention
summary = StringPrintf(_("Sync problem."));
body = StringPrintf(_("Sorry, there's a problem with your sync that you need to attend to."));
//TODO: set config information for 'sync-ui'
m_notificationManager->publish(summary, body);
}
}
}
// keep session around to give clients a chance to query it
m_server.delaySessionDestruction(m_session);
m_session.reset();
}
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
void AutoSyncManager::anySyncDone(AutoSyncTask *task, SyncMLStatus status)
{
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
// set "permanently failed" flag according to most recent result
task->m_permanentFailure = status != STATUS_OK && !ErrorIsTemporary(status);
SE_LOG_DEBUG(NULL, "auto sync: sync session %s done, result %d %s",
D-Bus server: fork/exec for sync, command line and restore operations This commit moves the blocking syncing, database restore and command line execution into a separate, short-lived process executing the syncevo-dbus-helper. The advantage is that the main syncevo-dbus-server remains responsive under all circumstances (fully asynchronous now) and suffers less from memory leaks and/or crashes during a sync. The core idea behind the new architecture is that Session remains the D-Bus facing side of a session. It continues to run inside syncevo-dbus-server and uses the syncevo-dbus-helper transparently via a custom D-Bus interface between the two processes. State changes of the helper are mirrored in the server. Later the helper might also be used multiple times in a Session. For example, anything related to loading backends should be moved into the helper (currently the "is config usable" check still runs in the syncevo-dbus-server and needs to load/initialize backends). The startup code of the helper already handles that (see boolean result of operation callback), but it is not used yet in practice. At the moment, only the helper provides a D-Bus API. It sends out signals when it needs information from the server. The server watches those and replies when ready. The helper monitors the connection to the parent and detects that it won't get an answer if that connection goes down. The problem of "helper died unexpectedly" is also handled, by not returning a D-Bus method reply until the requested operation is completed (different from the way how the public D-Bus API is defined!). The Connection class continues to use such a Session, as before. It's now fully asynchronous and exchanges messages with the helper via the Session class. Inside syncevo-dbus-server, boost::signals2 and the dbus-callbacks infrastructure for asynchronous methods execution are used heavily now. The glib event loop is entered exactly once and only left to shut down. Inside syncevo-dbus-helper, the event loop is entered only as needed. Password requests sent from syncevo-local-sync to syncevo-dbus-helper are handled asynchronously inside the event loop driven by the local transport. syncevo-dbus-helper and syncevo-local-sync are conceptually very similar. Should investigate whether a single executable can serve both functions. The AutoSyncManager was completely rewritten. The data structure is a lot simpler now (basically just a cache of transient information about a sync config and the relevant config properties that define auto syncing). The main work happens inside the schedule() call, which verifies whether a session can run and, if not possible for some reasons, ensures that it gets invoked again when that blocker is gone (timeout over, server idle, etc.). The new code also uses signals/slots instead of explicit coupling between the different classes. All code still lives inside the src/dbus/server directory. This simplifies checking differences in partly modified files like dbus-sync.cpp. A future commit will move the helper files. The syslog logger code is referenced by the server, but never used. This functionality needs further thought: - Make usage depend on command line option? Beware that test-dbus.py looks for the "ready to run" output and thus startup breaks when all output goes to syslog instead of stdout. - Redirect glib messages into syslog (done by LogRedirect, disabled when using LoggerSyslog)? The syncevo-dbus-server now sends the final "Session.StatusChanged done" signal immediately. The old implementation accidentally delayed sending that for 100 seconds. The revised test-dbus.py checks for more "session done" quit events to cover this fix. Only user-visible messages should have the INFO level in any of the helpers. Messages about starting and stopping processes are related to implementation details and thus should only have DEBUG level. The user also doesn't care about where the operation eventually runs. All messages related to it should be in INFO/DEBUG/ERROR messages without a process name. Therefore now syncevo-dbus-server logs with a process name (also makes some explicit argv[0] logging redundant; requires changes in test-dbus.py) and syncevo-dbus-helper doesn't. syncevo-local-sync is different from syncevo-dbus-helper: it produces user-relevant output (the other half of the local sync). It's output is carefully chosen so that the process name is something the user understands (target context) and output can be clearly related to one side or the other (for example, context names are included in the sync table). Output handling is based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. stderr and stdout are redirected into the parent and logged there as error. Normally the child should not print anything. While it runs, LogRedirect inside it will capture output and log it internally. Anything reaching the parent thus must be from early process startup or shutdown. Almost all communication from syncevo-dbus-helper to syncevo-dbus-server is purely information for the syncevo-dbus-server; syncevo-dbus-helper doesn't care whether the signal can be delivered. The only exception is the information request, which must succeed. Instead of catching exceptions everywhere, the optional signals are declared as such in the EmitSignal template parameterization and no longer throw exceptions when something goes wrong. They also don't log anything, because that could lead to quite a lof of output.
2012-03-26 17:19:25 +02:00
task->m_configName.c_str(),
status,
task->m_permanentFailure ?
"is a permanent failure" :
status == STATUS_OK ?
"is success" :
"is temporary failure");
}
SE_END_CXX