2.11. Component Timeout Value Locations

The MCollective timeout is configured on the broker, and is used for MCollective messages being sent from the broker to the node. If the message is lost after it is sent, or the node takes longer than expected to complete a request, this timeout will be hit.

The MCollective client timeout is used to ensure that you have a valid and active connection to your messaging broker. Lowering the defined amount causes a quicker switch to a redundant system in the event of a failure.

The node discovery timeout represents the allowed amount of time a node takes to acknowledge itself in the environment, instead of broadcasting to all nodes. This method of discovery is generally used in non-direct calls to the nodes. For example, when an application is created, when some administration commands are used, and some ssh key operations are performed.

The Facts timeout is configured on both the broker and node, and is for determining the allowed amount of time for a fact to be gathered from a node through MCollective. An example of a fact is when an application is created, and in doing so, the node's profile determines which node will perform the action. Facts are gathered often, so this timeout is short.

The Apache timeout is configured on the broker and node, and represents the timeout of proxy requests. This affects most requests, as they go through a proxy on both the broker and on the node. The ProxyTimeout on the broker affects requests to the broker API and rhc. If the timeout is exceeded due to lengthy requests, the client will receive an uninformative HTTP 502 error, even though the request may have succeeded. The ProxyTimeout on a node affects requests to hosted applications.

The rhc timeout represents the allowed amount of time that the client tools will wait for a request to be completed before ceasing the attempt. This only has to be configured on the client where rhc is run. If an action is taking longer to complete than expected, this timeout will be hit.

The background thread timeout is found on the broker, and determines how long requests from the console to the broker will take to be completed before ceasing the attempt. This communication is impacted by the amount of applications, domains, and gears an application developer has access to, as well as the locations of the datacenters that make up the OpenShift Enterprise deployment.