Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Remove documentation of legacy frontend_proxy worker app #13645

Merged
merged 1 commit into from
Aug 30, 2022
Merged

Remove documentation of legacy frontend_proxy worker app #13645

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/13645.doc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Remove documentation of legacy `frontend_proxy` worker app.
2 changes: 2 additions & 0 deletions docs/systemd-with-workers/workers/generic_worker.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@ worker_name: generic_worker1
worker_replication_host: 127.0.0.1
worker_replication_http_port: 9093

worker_main_http_uri: http://localhost:8008/

worker_listeners:
- type: http
port: 8083
Expand Down
61 changes: 20 additions & 41 deletions docs/workers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,23 +117,23 @@ redis:
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
public internet; it has no authentication and is unencrypted.


### Worker configuration

In the config file for each worker, you must specify the type of worker
application (`worker_app`), and you should specify a unique name for the worker
(`worker_name`). The currently available worker applications are listed below.
You must also specify the HTTP replication endpoint that it should talk to on
the main synapse process. `worker_replication_host` should specify the host of
the main synapse and `worker_replication_http_port` should point to the HTTP
replication port. If the worker will handle HTTP requests then the
`worker_listeners` option should be set with a `http` listener, in the same way
as the `listeners` option in the shared config.
In the config file for each worker, you must specify:
* The type of worker (`worker_app`). The currently available worker applications are listed below.
* A unique name for the worker (`worker_name`).
* The HTTP replication endpoint that it should talk to on the main synapse process
(`worker_replication_host` and `worker_replication_http_port`)
* If handling HTTP requests, a `worker_listeners` option with an `http`
listener, in the same way as the `listeners` option in the shared config.
* If handling the `^/_matrix/client/v3/keys/upload` endpoint, the HTTP URI for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my own edification-why is this required? (Not questioning, just curious)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which bit, in particular?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@H-Shay I guess you're asking about worker_main_http_uri? In which case, the answer is that /_matrix/client/v3/keys/upload is sometimes processed locally on the worker, but sometimes needs passing over to the main process; and the way it does the latter is very hacky and just an HTTP hit on the main process's regular HTTP interface.

#13642 is about improving this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was it, thank you for explaining!

the main process (`worker_main_http_uri`).

For example:

Expand Down Expand Up @@ -217,10 +217,12 @@ information.
^/_matrix/client/(api/v1|r0|v3|unstable)/search$

# 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/changes$
^/_matrix/client/(r0|v3|unstable)/keys/claim$
^/_matrix/client/(r0|v3|unstable)/room_keys/
^/_matrix/client/(r0|v3|unstable)/keys/upload/

# Registration/login requests
^/_matrix/client/(api/v1|r0|v3|unstable)/login$
Expand Down Expand Up @@ -581,39 +583,16 @@ handle it, and are online.
If `update_user_directory` is set to `false`, and this worker is not running,
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

*Note:* Historically there used to be more apps, however they have been
amalgamated into a single `synapse.app.generic_worker` app. The remaining apps
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
all these to be folded into the `generic_worker` app and to use config to define
which processes handle the various proccessing such as push notifications.
Comment on lines -612 to -616
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this information about intended direction is terribly helpful here: users aren't interested in the five-year-plan; they want to know how it works today.

The following used to be separate worker application types, but are now
equivalent to `synapse.app.generic_worker`:

* `synapse.app.client_reader`
* `synapse.app.event_creator`
* `synapse.app.federation_reader`
* `synapse.app.frontend_proxy`
* `synapse.app.synchrotron`


## Migration from old config
Expand Down