-
Notifications
You must be signed in to change notification settings - Fork 192
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
…5960) The `DaemonClient` provides a number of methods that will attempt to communicate with the daemon process, e.g., `stop_daemon` and `get_status`. This is done through the `CircusClient`, as the main daemon process is the circus daemonizer, which takes a timeout as argument indicating the number of seconds after which the call should raise if the daemon did not respond in time. The default timeout is set in the constructor of the `DaemonClient` based on the `daemon.timeout` config option. It was incorrectly getting the global value instead of the profile specific one, which is corrected by using `config.get_option('daemon.timeout', scope=profile.name)` to fetch the conifg option. A `timeout` argument is added to all `DaemonClient` methods that call through to the `CircusClient` that can be used to override the default that is based on the `daemon.timeout` config option. A default is added for `wait` in the `restart_daemon` method, to homogenize its interface with `start_daemon` and `stop_daemon`. The manual timeout cycle in `stop_daemon` by calling `_await_condition` has been removed as this functionality is already performed by the circus client itself and so is superfluous. The only place it is still used is in `start_daemon` because there the circus client is not used, since the circus process is not actually running yet, and a "manual" health check needs to be performed after the daemon process is launched. The manual check is added to the `stop_daemon` fixture since the check in certain unit test scenarios could give a false positive without an additional manual grace period for `is_daemon_running` to start returning `False`. The default for the `daemon.timeout` configuration option is decreased to 2 seconds, as this should be sufficient for most conditions for the circus daemon process to respond. Note that this daemon process is only charged with monitoring the daemon workers and so won't be under heavy load that will prevent it from responding in time.
- Loading branch information
Showing
6 changed files
with
130 additions
and
72 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,46 @@ | ||
.. todo:: | ||
.. _topics:daemon: | ||
|
||
.. _topics:daemon: | ||
****** | ||
Daemon | ||
****** | ||
|
||
****** | ||
Daemon | ||
****** | ||
AiiDA provides a daemon process that runs in the background which handles any new processes (i.e., calculations and workflows, see :ref:`process concepts <topics:processes:concepts>`) that are submitted. | ||
Unlike when running a process, which blocks the current Python interpreter (see the :ref:`launching <topics:processes:usage:launching>` section for details on the difference between *run* and *submit*), the daemon can handle multiple processes asynchronously. | ||
|
||
`#4016`_ | ||
The daemon concept in AiiDA consists of multiple *system processes*. | ||
|
||
.. note:: | ||
|
||
.. _#4016: https://github.com/aiidateam/aiida-core/issues/4016 | ||
System processes, here, refers to processes that are run by the operating system, not to the AiiDA specific collective term for all calculations and workflows. | ||
|
||
When the daemon is started, a single system process is launched in the background that runs indefinitely until it is stopped. | ||
This daemonized process is responsible for launching and then monitoring one or multiple daemon *workers*. | ||
Each daemon worker is another system process that connects to RabbitMQ to retrieve calculations and workflows that have been submitted and run them to completion. | ||
If a daemon worker dies, the daemon will automatically revive it. | ||
When the daemon is requested to stop, it will send a signal to all workers to shut them down before shutting down itself. | ||
|
||
In summary: AiiDA's daemon consists of a single system process running in the background (the daemon) that manages one or more system processes that handle all submitted calculations and workflows (the daemon workers). | ||
|
||
|
||
.. _topics:daemon:client: | ||
|
||
====== | ||
Client | ||
====== | ||
|
||
The Python API provides the :class:`~aiida.engine.daemon.client.DaemonClient` class to interact with the daemon. | ||
It can either be constructed directly for a given profile, or the :func:`aiida.engine.daemon.client.get_daemon_client` function can be used to construct it for the current default profile. | ||
The main methods of interest for interacting with the daemon are: | ||
|
||
* :meth:`~aiida.engine.daemon.client.DaemonClient.start_daemon` | ||
* :meth:`~aiida.engine.daemon.client.DaemonClient.restart_daemon` | ||
* :meth:`~aiida.engine.daemon.client.DaemonClient.stop_daemon` | ||
* :meth:`~aiida.engine.daemon.client.DaemonClient.get_status` | ||
|
||
These methods will raise a :class:`~aiida.engine.daemon.client.DaemonException` if the daemon fails to start or calls to it fail. | ||
All methods accept a ``timeout`` argument, which is the number of seconds the client should wait for the daemon process to respond, before raising a :class:`~aiida.engine.daemon.client.DaemonTimeoutException`. | ||
The default for the ``timeout`` is taken from the ``daemon.timeout`` configuration option and is set when constructing the :class:`~aiida.engine.daemon.client.DaemonClient`. | ||
|
||
.. note:: | ||
|
||
The ``DaemonClient`` only directly interacts with the main daemon process, not with any of the daemon workers that it manages. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters