This commit is contained in:
devonh 2024-10-03 22:03:19 +00:00
parent 2910a8252c
commit f170738b97
5 changed files with 16 additions and 6 deletions

View file

@ -1873,7 +1873,7 @@ v1.61.0.</p>
<tr><td>v1.85.0 v1.91.2</td><td>v1.83.0</td></tr>
<tr><td>v1.92.0 v1.97.0</td><td>v1.90.0</td></tr>
<tr><td>v1.98.0 v1.105.0</td><td>v1.96.0</td></tr>
<tr><td>v1.105.1 v1.115.0</td><td>v1.100.0</td></tr>
<tr><td>v1.105.1 v1.116.0</td><td>v1.100.0</td></tr>
</tbody></table>
<h2 id="upgrading-from-a-very-old-version"><a class="header" href="#upgrading-from-a-very-old-version">Upgrading from a very old version</a></h2>
<p>You need to read all of the upgrade notes for each version between your current
@ -7557,7 +7557,12 @@ Defaults to <code>true</code>.</p>
by running a <a href="usage/configuration/../../workers.html#synapseappgeneric_worker"><code>generic_worker</code></a> and adding it's <a href="usage/configuration/config_documentation.html#worker_name"><code>worker_name</code></a> to
a <code>federation_sender_instances</code> map. Doing so will remove handling of this function from
the main process. Multiple workers can be added to this map, in which case the work is
balanced across them.</p>
balanced across them. </p>
<p>The way that the load balancing works is any outbound federation request will be assigned
to a federation sender worker based on the hash of the destination server name. This
means that all requests being sent to the same destination will be processed by the same
worker instance. Multiple <code>federation_sender_instances</code> are useful if there is a federation
with multiple servers.</p>
<p>This configuration setting must be shared between all workers handling federation
sending, and if changed all federation sender workers must be stopped at the same time
and then started, to ensure that all instances are running with the same config (otherwise

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

View file

@ -267,7 +267,7 @@ v1.61.0.</p>
<tr><td>v1.85.0 v1.91.2</td><td>v1.83.0</td></tr>
<tr><td>v1.92.0 v1.97.0</td><td>v1.90.0</td></tr>
<tr><td>v1.98.0 v1.105.0</td><td>v1.96.0</td></tr>
<tr><td>v1.105.1 v1.115.0</td><td>v1.100.0</td></tr>
<tr><td>v1.105.1 v1.116.0</td><td>v1.100.0</td></tr>
</tbody></table>
<h2 id="upgrading-from-a-very-old-version"><a class="header" href="#upgrading-from-a-very-old-version">Upgrading from a very old version</a></h2>
<p>You need to read all of the upgrade notes for each version between your current

View file

@ -3898,7 +3898,12 @@ Defaults to <code>true</code>.</p>
by running a <a href="../../workers.html#synapseappgeneric_worker"><code>generic_worker</code></a> and adding it's <a href="#worker_name"><code>worker_name</code></a> to
a <code>federation_sender_instances</code> map. Doing so will remove handling of this function from
the main process. Multiple workers can be added to this map, in which case the work is
balanced across them.</p>
balanced across them. </p>
<p>The way that the load balancing works is any outbound federation request will be assigned
to a federation sender worker based on the hash of the destination server name. This
means that all requests being sent to the same destination will be processed by the same
worker instance. Multiple <code>federation_sender_instances</code> are useful if there is a federation
with multiple servers.</p>
<p>This configuration setting must be shared between all workers handling federation
sending, and if changed all federation sender workers must be stopped at the same time
and then started, to ensure that all instances are running with the same config (otherwise