qq游戏里有十三水这个游戏吗 www.tdgb.net Links
Top Level Elements
The Cluster Valve object
A cluster valve is no different from any other Tomcat
The cluster valves are interceptors in the invocation chain for HTTP requests, and the clustering implementation
uses these valves to make intelligent decision around data and when data should be replicated.
A cluster valve must implement the
This is a simple interface that extends the
ReplicationValve will notify the cluster at the end of a HTTP request
so that the cluster can make a decision whether there is data to be replicated or not.
Set value to |
For known file extensions or urls, you can use this Valve to notify the
cluster that the session has not been modified during this request and
the cluster doesn't have to probe the session managers for changes. If
the request matches this filter pattern, the cluster assumes there has
been no session change. An example filter would look like |
. The filter is a regular expression using
Boolean value, so to true, and the replication valve will insert a request attribute with the name
defined by the |
The value inserted into the request attribute is either
Default value is |
The value defined here is the name of the request attribute that contains the boolean value
if the session is primary on this server or not.
Boolean value. Set to |
true if you want the valve to collect request statistics.
Default value is
In case of a mod_jk failover, the
JvmRouteBinderValve will replace the
jvmWorker attribute in the session Id, to make future requests stick to this
node. If you want failback capability, don't enable this valve, but if you want your failover to stick,
and for mod_jk not to have to keep probing the node that went down, you use this valve.
Default value is |
Runtime attribute to turn on and off turn over of the session's jvmRoute value.
Old sessionid before failover is registered in request attributes with this attribute.
Default attribute name is |
ClusterSingleSignOn supports feature of single sign on in cluster.
ClusterSingleSignOn, the security identity authenticated
by one web application is recognized by other web applications on the same virtual host,
and it is propagated to other nodes in the cluster.
See the Single Sign On special
feature on the Host element for more information.
Note: ClusterSingleSignOn can be configured at host level cluster only.
Java class name of the implementation to use. This MUST be set to
Sets the host domain to be used for sso cookies.
The Valve uses a replicated map. You can setup the flag for how this
map sends messages. The default value is
Note that if you use asynchronous messaging it is possible for update
messages to be processed by the receiving node in a different order to
the order in which they were sent.
Default false. Flag to determine whether each request needs to be
reauthenticated to the security Realm. If "true", this
Valve uses cached security credentials (username and password) to
reauthenticate to the Realm each request associated
with an SSO session. If "false", the Valve can itself authenticate
requests based on the presence of a valid SSO cookie, without
rechecking with the Realm.
The Valve uses a replicated map. This is the timeout for messages
that transfer state to/from the other nodes in the cluster. If not
specified, a default value of
15000 milliseconds is used.
true if you wish this Valve to fail if the
underlying replication fails to start. If the Valve fails, then the
associated container will fail to start. If you set this attribute to
false, and the underlying replications fails to start, the Valve will
start and it will attempt to join the cluster and start replication as
part of the heartbeat process. If not specified, the default value of
false is used.