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 in 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 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 activate.
$ vespa-configproxy-cmd -m setmode memorycache
To inspect the configuration for a service, in this example a searchnode (proton) instance, do:
$ vespa-configproxy-cmd | grep proton vespa.config.search.core.proton,music/search/cluster.music/0,2,MD5:40087d6195cedb1840721b55eb333735,XXHASH64:43829e79cea8e714
vespa.config.search.core.protonis the config definition name for this particular config,
music/search/cluster.music/0is the config id used by the proton service instance on this node and
2is the active config generation. This means, the service is using the correct config generation as it is matching the /state/v1/config response (a restart can be required for some config changes).
$ vespa-get-config -n vespa.config.search.core.proton -i music/search/cluster.music/0 basedir "/opt/vespa/var/db/vespa/search/cluster.music/n0" rpcport 19106 httpport 19110 ...
-iwill return the default configuration, meaning not generated for the active service instance.