Some of you may want to run multiple instances of moxi, giving each moxi process special command-line configuration parameters. The simplest way to start moxi completely via the command-line is by passing it one or more comma-separated REST URL's:

shell> moxi URL1[,URL2[,URLn]]

For example:

shell> moxi http://membase0:8091/pools/default/bucketsStreaming/shoppingCarts,http://membase1:8091/pools/default/bucketsStreaming/shoppingCarts

On startup moxi will contact each URL in the provided order, until one of the URL's succeeds in returning a valid REST response. The connection that moxi creates to the URL is persistent; neither Couchbase server nor moxi will close the HTTP connection. Therefore Couchbase server can stream cluster topology update information to moxi as needed. If moxi loses its persistent HTTP connection to a URL, it will attempt to find a running Couchbase server using the URL's provided in the start command. In other words, moxi will first attempt to reconnect to Couchbase server using URL's provided at the beginning of the command, and if needed, then proceed to subsequent URLs.

A per-bucket URL has the form of:

http://<MEMBASE_SERVER>:8091/pools/default/bucketsStreaming/<BUCKET_NAME>

For example, with a bucket named "shoppingCarts":

shell> moxi http://membase1:8091/pools/default/bucketsStreaming/shoppingCarts

And using more than one Couchbase server for redundancy:

shell> moxi http://membase0:8091/pools/default/bucketsStreaming/shoppingCarts,http://membase1:8091/pools/default/bucketsStreaming/shoppingCarts

The "Gold Standard" best practice (if you have the flexibility) is to put the Couchbase host URLs behind a http reverse-proxy, so that all the client-side Moxi's can be more easily configured with a "stable" URL which can handle cluster changes without having to touch each client-side Moxi like..

shell> moxi http://membase_http_reverse_proxy_host:8091/pools/default/bucketsStreaming/<BUCKET_NAME>

Certain HTTP reverse proxies or load balancers will close a connection that they have deemed idle. When a client-side Moxi is connected to Couchbase's streaming API, there is very little data flowing unless topology changes occur. Because of this, some load balancers will close the connection which can cause traffic disruptions. It is a best practice to configure the load balancer with an infinite timeout on idle connections for this traffic.

Additionally, some HTTP reverse proxies or load balancers can provide 'round robin' load balancing; such features should be avoided. Because clients connect to the HTTP reverse-proxy/load-balancer, the reverse- proxy/load-balancer in 'round-robin' mode will choose the next server on its list to forward the connection. Instead the HTTP reverse-proxy/load-balancer should be configured to use either a 'source' mode (different reverse-proxies/load- balancers have different terms for this concept), where the same HTTP client from a given IP address would be proxy for the same HTTP server.

Changing the default listening port

Moxi will listen on port 11211 by default. To change Moxi's listen port, use a -Z port_listen flag:

shell> moxi -Z port_listen=11311 http://membase1:8091/pools/default/bucketsStreaming/shoppingCarts

Specifying SASL authentication

If your bucket has SASL authentication credentials, you can also specify them using the usr and pwd -Z flags. For example:

shell> moxi -Z usr=shoppingCarts,pwd=need_a_better_pswd,port_listen=11311 \
    http://membase1:8091/pools/default/bucketsStreaming/shoppingCarts

Increased Logging

To have moxi emit more logging information, you can specify -v, -vv, or -vvv flags (the more v's, the more verbose moxi will be). For example:

shell> moxi -vv -Z usr=shoppingCarts,pwd=need_a_better_pswd,port_listen=11311  \
    http://membase1:8091/pools/default/bucketsStreaming/shoppingCarts