< KDE PIM | Akonadi Revision as of 17:14, 3 May 2013 (view source)Cmollekopf (talk | contribs)← Older edit Revision as of 09:56, 7 September 2015 (view source) Dvratil (talk | contribs) (→Directories: Port to KF5)Newer edit → Line 41: Line 41: * .config/akonadi/instance/$IDENTIFIER * .config/akonadi/instance/$IDENTIFIER * .local/share/akonadi/instance/$IDENTIFIER * .local/share/akonadi/instance/$IDENTIFIER −* .kde4/share/config/akonadi/akonadi_imap_resource_0_$IDENTIFIERrc+* .config/akonadi/akonadi_imap_resource_0_$IDENTIFIERrc To cleanup an instance, just delete all the directories and configs above. To cleanup an instance, just delete all the directories and configs above. Revision as of 09:56, 7 September 2015 Warning This does not yet work with any akonadi agents/resource as they need to be ported first (only akonadiconsole has been ported so far). Don't use it unless you know what you're doing. Contents 1 Akonadi Multi-Instance Setup 2 Usage 2.1 Directories 2.2 Akonadi Clients 2.3 Akonadi Console 2.4 Risks and Missing Features 2.5 Development Akonadi Multi-Instance Setup The multi-instance Akonadi setup allows to run multiple Akonadi servers in parallel, using the same posix-user and D-Bus session bus. D-Bus service names are postfixed with an instance identifier and all relevant configuration files/directories are either postfixed or put in a separate directory, to avoid any clashes, making it safe to run multiple instances in parallel. The behavior of a normal Akonadi instance is not changed. To run multiple Akonadi instances in parallel it is required to assign to each instance a unique identifier using: akonadictl --instance IDENTIFIER start An application will then connect to a server depending on the AKONADI_INSTANCE environment variable (set to IDENTIFIER). You can run a normal Akonadi instance (without --instance) in parallel with multi-instance Akonadi instances. Each instance will run it's own Mysql server by default, just like a regular Akonadi instance does. Usage start instance: export AKONADI_DISABLE_AGENT_AUTOSTART akonadictl --instance IDENTIFIER start connect any Akonadi client (see also risks section below): export AKONADI_INSTANCE=IDENTIFIER akonadiconsole stop instance: akonadictl --instance IDENTIFIER stop Directories The multi-instance setup puts it's files in the following directories: .config/akonadi/instance/$IDENTIFIER .local/share/akonadi/instance/$IDENTIFIER .config/akonadi/akonadi_imap_resource_0_$IDENTIFIERrc To cleanup an instance, just delete all the directories and configs above. Akonadi Clients To connect to an instance using a Akonadi client application, export the following environment variable first (with inst1 being the instance identifier): export AKONADI_INSTANCE=inst1 Akonadi Console Unlike regular client applications, akonadiconsole will automatically detect the presence of multiple Akonadi instances and asks to which one to connect to if more than one was found. Some of the debugging facilities do not work correctly yet, these are the known issues: Raw socket always connects to the main instance. Protocol debugger always uses the main instance. Job tracker and resource scheduler view show activity from all instances. Notification monitor always uses the main instance. You can also connect to the Mysql instance directly using the Mysql console (standalone, not the akonadiconsole one): mysql --protocol=SOCKET --socket=~/.local/share/akonadi/instance/<inst1>/socket-<hostname>/mysql.socket Risks and Missing Features Debugging facilities in akonadiconsole as mentioned above Firstrun: Is disabled in servermanager.cpp, otherwise the firstrun code will crash (an assert prevents running the code since it is unsafe so far). It is not safe to run a multi-instance setup without exporting AKONADI_DISABLE_AGENT_AUTOSTART first, because the default setup desktop files contain configs with hardcoded paths, which would result in every akonadi instance creating a resource for the same default path. Most client applications do not namespace their configuration files according to the Akonadi instance they connect to. Using the same configuration on two different instances can have arbitrary side-effects. It is for example not safe to run Kontact/KMail against a second instance. Development In order to make Akonadi code work in the multi-instance setup all unique identifiers need to be made distinguishable between instances. That includes most prominently: D-Bus service names configuration file names default directory paths You only need to change these, if you add/use D-Bus interfaces, or access configuration files directly. Most things have already been taken care of using the AgentBase/ResourceBase classes. kdepimlibs/akonadi/servermanager.h contains a couple of helper functions to help with that. Note that it is not possible to change the D-Bus names or the prefixed directories just in kdepimlibs, as the Akonadi server makes assumptions on where to find the directories and D-Bus services. Retrieved from "https://techbase.kde.org/index.php?title=KDE_PIM/Akonadi/Multi-Instance&oldid=85779" Content is available under Creative Commons License SA 4.0 unless otherwise noted.