ModCluster Management Protocol

For node and balancer configuration keys refer to ModCluster Node and Balancer.

Like ENABLE-APP.

Like ENABLE-APP.

Like ENABLE-APP.

That is a response to STOP-APP, like a http response it starts with HTTP/1.1 200 OK<CR><LF> and it has the format:

Note that a Wildcard STOP-APP won’t cause a STOP-APP-RSP but just a 200 or 500.

That is a response, like a http response it starts with HTTP/1.1 200 OK<CR><LF> and it has the format:

Empty request.

"readable" description of the mod_cluster configuration corresponding to the messages the cluster has sent to mod_cluster.

Empty request.

"readable" description of the mod_cluster configuration corresponding to the messages the cluster has sent to mod_cluster.

There are 3 different pings: (for version 0.1.0 on).

In case a -APP command with wildcard is sent by ModClusterManager to mod_cluster only the JVMRoute is going to be relevant in the payload message.

For example:

will be handled like:

Other values between the command and HTTP/1.0 (or 1.1) are ignored in the actual version of the protocol.

A shutdown of a node will cause the following events:

(ModCluster Design suggests that ModClusterManager should wait until all sessions have been finished but that requires a to be written tool. The idea is that an administrator initiated step; similar to what people do now by changing workers.properties to quiesce a node in mod_jk, but it could be initiated from the JBoss side via a management tool). If a request arrives for a context corresponding to this node 500 will be returned to the client.

An additional utility could be written to send a REMOVE-APP once the JBoss node is stopped REMOTE-APP will remove all the node information from mod_cluster table and any socket between httpd and the node will be closed. (For a more complete description see ModCluster Internals.) If a request arrives for a context corresponding to this node 404 will be returned to the client: in fact the mod_proxy will not be called for the request and an httpd page could be displayed. A REMOVE-APP / for example will just clean the mod_cluster table corresponding to the application defined in the payload.

Once a error occurs in mod_cluster 500 is returned and the status line tells the version of protocol mod_cluster is using and a short description of the error.

The error response status line will be something like:

Where version_supported is the version of the protocol mod_cluster is able to support.

Where type is the type of error, for example: MEM to tell the message contains syntax errors (SYNTAX) or the data can’t be updated to update the shared memory (MEM).

The "error_string" should help to understand what was wrong and the n.p.n VERSION information tells which highest version of the protocol mod_cluster understands.

The first part of the error_string should help to make a decision how to go on:

SYNTAX: mod_cluster can’t understand the message or part of the message. Another version of the protocol should used or ModClusterService should be fixed.

MEM: mod_cluster can’t update the shared memory. If that is the answer to a -APP messages or a STATUS message new CONFIG message should be send. If it is the answer to a CONFIG message the configuration of the cluster in ModCusterService should be checked or/and the CONFIG message should be resend to mod_cluster.

Example:

The mod_cluster-manager handler allows to do operation like ENABLE_APP/DISABLE_APP through a web interface. The format of the request string is the following:

where:

Example