Moxi's startup codepaths are slightly different, depending if you have a static configuration or a dynamic configuration. For example, you have a static configuration (where moxi has all the complete info it needs to operate) if you start moxi like:
./moxi -z 11211=memcached1,memcached2,memcached3You have a dynamic configuration when moxi needs to gets a full configuration from some remote system, and there might be delays. For example:
./moxi -z url=http://HOST:8080/pools/default/bucketsStreaming/defaultWhen moxi knows its listen ports and cluster at start-time:
The main thread parses cmd-line parameters.
The main thread then creates one or more listening sockets.
The main thread then spawns the specified number of worker threads.
The main thread then goes into the libevent main event loop, awaiting connections from clients or other work tasks.
When moxi goes through dynamic configuration:
The main thread parses cmd-line parameters.
The main thread then passes config info, such as URL's, to libconflate.
The main thread then spawns the specified number of worker threads. (same as above)
The main thread then goes into the libevent main event loop, awaiting connections from clients or other work tasks. (same as above)
Libconflate spawns a separate thread to make REST calls and process REST/JSON configuration responses.
When the libconflate thread receives a proper REST/JSON configuration, it puts a re-configuration work task on the main thread's work queue.
The work queue functionality is the main way that threads communicate between each other in moxi.