From 37b0c8b51348d6908a8a2e9086923ee8a24789e5 Mon Sep 17 00:00:00 2001
From: DMRobertson localhost:8083
in the above example).
synctl
or your distribution's preferred service manager such as systemd
. We
recommend the use of systemd
where available: for information on setting up
systemd
to start synapse workers, see
-Systemd with Workers. To use synctl
, see
+Systemd with Workers. To use synctl
, see
Using synctl with Workers.
synapse.app.generic_worker
event_creator
listens for requests from clients to create new ev
so. It will then pass those events over HTTP replication to any configured event
persisters (or the main process if none are configured).
Note that event_creator
s and event_persister
s are implemented using the same
-synapse.app.generic_worker
.
synapse.app.generic_worker
.
An example stream_writers
configuration with multiple writers:
stream_writers:
@@ -565,7 +565,8 @@ worker_log_config: /etc/matrix-synapse/background-worker-log.yaml
You can designate one generic worker to update the user directory.
-Specify its name in the shared configuration as follows:
+Specify its name in the shared configuration +as follows:
update_user_directory_from_worker: worker_name
This work cannot be load-balanced; please ensure the main process is restarted @@ -581,16 +582,36 @@ worker application type.
You can designate one generic worker to send output traffic to Application Services. Doesn't handle any REST endpoints itself, but you should specify its name in the -shared configuration as follows:
+shared configuration +as follows:notify_appservices_from_worker: worker_name
This work cannot be load-balanced; please ensure the main process is restarted after setting this option in the shared configuration!
This style of configuration supersedes the legacy synapse.app.appservice
worker application type.
You can designate generic worker to sending push notifications to +a push gateway such as +sygnal and email.
+This will stop the main process sending push notifications.
+The workers responsible for sending push notifications can be defined using the
+pusher_instances
+option. For example:
pusher_instances:
+ - pusher_worker1
+ - pusher_worker2
+
+Multiple workers can be added to this map, in which case the work is balanced +across them. Ensure the main process and all pusher workers are restarted after changing +this option.
+These workers don't need to accept incoming HTTP requests to send push notifications, +so no additional reverse proxy configuration is required for pusher workers.
+This style of configuration supersedes the legacy synapse.app.pusher
+worker application type.
synapse.app.pusher
It is likely this option will be deprecated in the future and is not recommended for new
-installations. Instead, use synapse.app.generic_worker
with the pusher_instances
.
synapse.app.generic_worker
with the pusher_instances
.
Handles sending push notifications to sygnal and email. Doesn't handle any
REST endpoints itself, but you should set
start_pushers: false
in the
@@ -623,7 +644,7 @@ shared configuration file to stop the main synapse sending appservice notificati
Note this worker cannot be load-balanced: only one instance should be active.
synapse.app.federation_sender
It is likely this option will be deprecated in the future and not recommended for
-new installations. Instead, use synapse.app.generic_worker
with the federation_sender_instances
.
synapse.app.generic_worker
with the federation_sender_instances
.
Handles sending federation traffic to other servers. Doesn't handle any
REST endpoints itself, but you should set
send_federation: false
@@ -687,7 +708,9 @@ worker_listeners:
worker_log_config: /etc/matrix-synapse/media-worker-log.yaml
Note that if running multiple media repositories they must be on the same server -and you must configure a single instance to run the background tasks, e.g.:
+and you must specify a single instance to run the background tasks in the +shared configuration, +e.g.:media_instance_running_background_jobs: "media-repository-1"
Note that if a reverse proxy is used , then /_matrix/media/
must be routed for both inbound client and federation requests (if they are handled separately).