Mirrors
/
synapse-old
mirror of https://github.com/matrix-org/synapse.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove documentation of legacy `frontend_proxy` worker app (#13645) 

This has been the same as a generic_worker since #6964, so let's get rid of it.

Fixes #3717
This commit is contained in:
Richard van der Hoff 2022-08-30 18:01:51 +01:00 committed by GitHub
parent 4249082eed
commit 372136d3a8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 23 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
changelog.d/13645.doc Normal file
View File

@ -0,0 +1 @@
Remove documentation of legacy `frontend_proxy` worker app.

2
docs/systemd-with-workers/workers/generic_worker.yaml
View File

@ -5,6 +5,8 @@ worker_name: generic_worker1
worker_replication_host: 127.0.0.1 worker_replication_host: 127.0.0.1
worker_replication_http_port: 9093 worker_replication_http_port: 9093
worker_main_http_uri: http://localhost:8008/
worker_listeners: worker_listeners:
- type: http - type: http
port: 8083 port: 8083

61
docs/workers.md
View File

@ -117,7 +117,7 @@ redis:
enabled: true enabled: true
``` ```
See the sample config for the full documentation of each option. See the [configuration manual](usage/configuration/config_documentation.html) for the full documentation of each option.
Under **no circumstances** should the replication listener be exposed to the Under **no circumstances** should the replication listener be exposed to the
public internet; replication traffic is: public internet; replication traffic is:
@ -128,15 +128,15 @@ public internet; replication traffic is:
### Worker configuration ### Worker configuration
In the config file for each worker, you must specify the type of worker In the config file for each worker, you must specify:
application (`worker_app`), and you should specify a unique name for the worker * The type of worker (`worker_app`). The currently available worker applications are listed below.
(`worker_name`). The currently available worker applications are listed below. * A unique name for the worker (`worker_name`).
You must also specify the HTTP replication endpoint that it should talk to on * The HTTP replication endpoint that it should talk to on the main synapse process
the main synapse process. `worker_replication_host` should specify the host of (`worker_replication_host` and `worker_replication_http_port`)
the main synapse and `worker_replication_http_port` should point to the HTTP * If handling HTTP requests, a `worker_listeners` option with an `http`
replication port. If the worker will handle HTTP requests then the listener, in the same way as the `listeners` option in the shared config.
`worker_listeners` option should be set with a `http` listener, in the same way * If handling the `^/_matrix/client/v3/keys/upload` endpoint, the HTTP URI for
as the `listeners` option in the shared config. the main process (`worker_main_http_uri`).
For example: For example:
@ -220,10 +220,12 @@ information.
^/_matrix/client/(api/v1|r0|v3|unstable)/search$ ^/_matrix/client/(api/v1|r0|v3|unstable)/search$
# Encryption requests # Encryption requests
# Note that ^/_matrix/client/(r0|v3|unstable)/keys/upload/ requires `worker_main_http_uri`
^/_matrix/client/(r0|v3|unstable)/keys/query$ ^/_matrix/client/(r0|v3|unstable)/keys/query$
^/_matrix/client/(r0|v3|unstable)/keys/changes$ ^/_matrix/client/(r0|v3|unstable)/keys/changes$
^/_matrix/client/(r0|v3|unstable)/keys/claim$ ^/_matrix/client/(r0|v3|unstable)/keys/claim$
^/_matrix/client/(r0|v3|unstable)/room_keys/ ^/_matrix/client/(r0|v3|unstable)/room_keys/
^/_matrix/client/(r0|v3|unstable)/keys/upload/
# Registration/login requests # Registration/login requests
^/_matrix/client/(api/v1|r0|v3|unstable)/login$ ^/_matrix/client/(api/v1|r0|v3|unstable)/login$
@ -584,39 +586,16 @@ handle it, and are online.
If `update_user_directory` is set to `false`, and this worker is not running, If `update_user_directory` is set to `false`, and this worker is not running,
the above endpoint may give outdated results. the above endpoint may give outdated results.
### `synapse.app.frontend_proxy`
Proxies some frequently-requested client endpoints to add caching and remove
load from the main synapse. It can handle REST endpoints matching the following
regular expressions:
^/_matrix/client/(r0|v3|unstable)/keys/upload
If `use_presence` is False in the homeserver config, it can also handle REST
endpoints matching the following regular expressions:
^/_matrix/client/(api/v1|r0|v3|unstable)/presence/[^/]+/status
This "stub" presence handler will pass through `GET` request but make the
`PUT` effectively a no-op.
It will proxy any requests it cannot handle to the main synapse instance. It
must therefore be configured with the location of the main instance, via
the `worker_main_http_uri` setting in the `frontend_proxy` worker configuration
file. For example:
```yaml
worker_main_http_uri: http://127.0.0.1:8008
```
### Historical apps ### Historical apps
*Note:* Historically there used to be more apps, however they have been The following used to be separate worker application types, but are now
amalgamated into a single `synapse.app.generic_worker` app. The remaining apps equivalent to `synapse.app.generic_worker`:
are ones that do specific processing unrelated to requests, e.g. the `pusher`
that handles sending out push notifications for new events. The intention is for * `synapse.app.client_reader`
all these to be folded into the `generic_worker` app and to use config to define * `synapse.app.event_creator`
which processes handle the various proccessing such as push notifications. * `synapse.app.federation_reader`
* `synapse.app.frontend_proxy`
* `synapse.app.synchrotron`
## Migration from old config ## Migration from old config