Read the config introduction
for an overview of the cloud config system.
The config proxy runs on every Vespa node.
It has a set of config sources, defined with the environment variable
The config proxy will act as a proxy for config clients on the same machine,
so that all clients can ask for config on localhost:19090.
The config source that the config proxy uses is set by the
VESPA_CONFIGSERVERS and may consist of one or more config sources
(usually config servers,
but may be other config proxies).
The proxy has a memory cache that is used to serve configs if it is possible. In default mode, the proxy will have an outstanding request to the config server that will return when the config has changed (a new generation of config). This means that every time config changes on the config server, the proxy will get a response, update its cache and respond to all its clients with the changed config.
The config proxy has two modes:
|default||Gets config from server and stores in memory cache. The config proxy will always be started in default mode. Serves from cache if possible. Always uses a config source. If restarted, it will lose all configs that were cached in memory.|
|memorycache||Serves config from memory cache only. Never uses a config source. A restart will lose all cached configs. Setting the mode to memorycache will make all applications on the node work as before (given that they have previously been running, and hence, requested config), since the config proxy will serve config from cache and work without any connection to the config server. Applications on this node will not work if the config proxy stops, is restarted or crashes.|
Interface with the config proxy using vespa-configproxy-cmd - run it without arguments to see usage. The tool displays heap usage for the proxy, displays the configs cached and flushes the cache. View the pending requests it has against the server(s). A pending request is the same as a subscription of server data, the requests are held open until the data changes on the server, through a vespa-deploy activate.
Use the upgrade procedure, but also detach hosts from config servers.
Use the memorycache mode for incompatible major upgrades. A config proxy can be detached from the config server, disconnecting from the config server, serving current config from its local snapshot:
$ vespa-configproxy-cmd -m setmode memorycache