delete app

Change-Id: Id4c572809969ebe89e946e88063eaed262cff3f2 Signed-off-by: hongbotian <hongbo.tianhongbo@huawei.com>
author: hongbotian <hongbo.tianhongbo@huawei.com> 2015-11-30 03:10:21 -0500
committer: hongbotian <hongbo.tianhongbo@huawei.com> 2015-11-30 03:10:21 -0500
commit: c0b7206652b2852bc574694e7ba07ba1c2acdc00 (patch)
tree: 5cb95cb0e19e03610525903df46279df2c3b7eb1 /rubbos/app/tomcat-connectors-1.2.32-src/xdocs/reference/workers.xml
parent: b6d3d6e668b793220f2d3af1bc3e828553dc3fe6 (diff)
1 files changed, 0 insertions, 1155 deletions
diff --git a/rubbos/app/tomcat-connectors-1.2.32-src/xdocs/reference/workers.xml b/rubbos/app/tomcat-connectors-1.2.32-src/xdocs/reference/workers.xml
deleted file mode 100644
index 543112cf..00000000
--- a/rubbos/app/tomcat-connectors-1.2.32-src/xdocs/reference/workers.xml
+++ /dev/null
@@ -1,1155 +0,0 @@
-<?xml version="1.0"?>
-<!--
-  Licensed to the Apache Software Foundation (ASF) under one or more
-  contributor license agreements.  See the NOTICE file distributed with
-  this work for additional information regarding copyright ownership.
-  The ASF licenses this file to You under the Apache License, Version 2.0
-  (the "License"); you may not use this file except in compliance with
-  the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
--->
-<!DOCTYPE document [
-  <!ENTITY project SYSTEM "project.xml">
-]>
-<document url="workers.html">
-
-    &project;
-
-    <properties>
-        <author email="mturk@apache.org">Mladen Turk</author>
-        <title>workers.properties configuration</title>
-    </properties>
-
-<body>
-
-<section name="Introduction">
-<br/>
-<p>
-A <b>Tomcat worker</b> is a Tomcat instance that is waiting to execute servlets or any other content
-on behalf of some web server. For example, we can have a web server such as
-Apache forwarding servlet requests to a Tomcat process (the worker) running behind it.
-</p>
-<p>
-The scenario described above is a very simple one;
-in fact one can configure multiple Tomcat workers to serve servlets on
-behalf of a certain web server.
-The reasons for such configuration can be:
-</p>
-<ul>
-<li>
-We want different contexts to be served by different Tomcat workers to provide a
-development environment where all the developers share the same web server but
-own a Tomcat worker of their own.
-</li>
-<li>
-We want different virtual hosts served by different Tomcat processes to provide a
-clear separation between sites belonging to different companies.
-</li>
-<li>
-We want to provide load balancing, meaning run multiple Tomcat workers each on a
-machine of its own and distribute the requests between them.
-</li>
-</ul>
-
-<p>
-There are probably more reasons for having multiple workers but I guess that this list is enough...
-</p>
-<p>
-Tomcat workers are defined in a properties file dubbed <b>workers.properties</b> and this tutorial
-explains how to work with it.
-</p>
-</section>
-
-<section name="Configuration File Basics">
-<br/>
-<p>Defining workers to the Tomcat web server plugin can be done using a properties file
-(a sample file named workers.properties is available in the conf/ directory).
-</p>
-
-<subsection name="Format, Comments, Whitespace">
-<br/>
-<p>
-The lines in the file define properties. The general format is
-</p>
-<p><strong>&lt;name&gt;=&lt;value&gt;</strong></p>
-<p>
-</p>
-Dots are used as part of the name to represent a configuration hierarchy.
-<p>
-Invalid directives will be logged during web server startup and prevent the web server
-from working properly. Some directives have been deprecated. Although they will
-still work, you should replace them by their
-<a href="#Deprecated Worker Directives">successors</a>.
-</p>
-<p>
-Some directives are allowed multiple times. This will be explicitly
-noted in the tables below.
-</p>
-<p>
-Whitespace at the beginning and the end of a property name or value gets ignored.
-Comments can be placed in any line and start with a hash sign '#'.
-Any line contents behind the hash sign get ignored.
-</p>
-</subsection>
-
-<subsection name="Global Properties">
-<br/>
-<p>
-These directives have global scope.
-</p>
-<directives>
-<directive name="worker.list" default="ajp13" required="true">
-A comma separated list of workers names that the JK will use. When starting up,
-the web server plugin will instantiate the workers whose name appears in the
-worker.list property, these are also the workers to whom you can map requests.
-<p>
-This directive can be used multiple times.
-</p>
-</directive>
-<directive name="worker.maintain" default="60" required="false">
-Worker connection pool maintain interval in seconds. If set to the positive
-value JK will scan all connections for all workers specified in worker.list
-directive and check if connections needs to be recycled.
-<p>
-Furthermore any load balancer does a global maintenance every worker.maintain
-seconds. During global maintenance load counters are decayed and workers
-in error are checked for recover_time.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.13</b>.
-</p>
-</directive>
-</directives>
-</subsection>
-
-<subsection name="Worker Properties">
-<br/>
-<p>
-Each worker configuration directive consists of three words separated by a dot:
-</p>
-<p><strong>worker.&lt;worker name&gt;.&lt;directive&gt;=&lt;value&gt;</strong></p>
-<p>
-The first word is always <b>worker</b>. 
-The second word is the worker name you can choose. In the case of load-balancing,
-the worker name has an additional meaning. Please consult the
-<a href="../generic_howto/loadbalancers.html">Load Balancer HowTo</a>.
-</p>
-<warn>
-The name of the worker can contain only the alphanumeric characters
-<b>[a-z][A-Z][0-9][_\-]</b> and is case sensitive.
-</warn>
-</subsection>
-
-<subsection name="Variables, Environment Variables">
-<br/>
-<p>
-You can define and use variables in the workers.properties file.
-To define a variable you use the syntax:
-</p>
-<p><strong>&lt;variable_name&gt;=&lt;value&gt;</strong></p>
-<p>
-Dots are allowed in the variable name, but you have to be careful
-not to use variable names, that clash with standard directives.
-Therefore variable names should never start with "worker.".
-</p>
-<p>
-To use a variable, you can insert "$(variable_name)" at any place
-on the value side of a property line. If a variable has not been
-defined before its use, we will search the process environment for
-a variable with the same name and use their value.
-</p>
-</subsection>
-
-<subsection name="Property Inheritance">
-<br/>
-<p>Often one wants to use the same property values for various workers.
-To reduce duplication of configuration lines and to ease the maintenance of
-the file, you can inherit properties from one worker to another, or even
-from a template to real workers.
-</p>
-<p>
-The directive "reference" allows to copy configurations between workers
-in a hierarchical way. If worker castor sets <b>worker.castor.reference=worker.pollux</b>
-then it inherits all properties of <b>pollux</b>, except for the ones that
-are explicitly set for <b>castor</b>.
-</p>
-<p>
-Please note, that the value of the directive is not only the name of the referred worker,
-but the complete prefix including "worker.".
-</p>
-<p>
-To use a template worker simply define it like a real worker, but do not add it
-to the "worker.list" or as a member to any load balancer. Such a template worker
-does not have to contain mandatory directives. This approach is especially useful,
-if one has a lot of balanced workers in a load balancer
-and these workers share most of their properties. You can set all of these properties
-in a template worker, e.g. using the prefix "worker.template1", and then simply
-reference those common properties in all balanced workers.
-</p>
-<p>
-References can be used to inherit properties over multiple hops in a hierarchical way.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.19</b>.
-</p>
-</subsection>
-</section>
-
-<section name="List of All Worker Directives">
-<br/>
-<subsection name="Mandatory Directives">
-<br/>
-<p>Mandatory directives are the one that each worker <b>must</b> contain. Without them the worker will
-be unavailable or will misbehave. Those directives will be marked with a <strong>strong</strong> font in the following tables.
-</p>
-<directives>
-<directive name="type" default="ajp13" required="true">
-Type of the worker (can be one of ajp13, ajp14, jni, lb or status). The type of the worker
-defines the directives that can be applied to the worker.
-<p>AJP13 worker is the preferred worker type that JK uses for communication
-between web server and Tomcat. This type of worker uses sockets as communication
-channel. For detailed description of the AJP13 protocol stack browse to
-<a href="../ajp/ajpv13a.html">AJPv13 protocol specification</a>
-</p>
-<warn>JNI workers have been deprecated. They will likely not work. Do not use them.</warn>
-</directive>
-</directives>
-</subsection>
-
-<subsection name="Connection Directives">
-<br/>
-<p>Connection directives defines the parameters needed to connect and maintain
-the connections pool of persistent connections between JK and remote Tomcat.
-</p>
-<directives>
-
-<directive name="host" default="localhost" required="false">
-Host name or IP address of the backend Tomcat instance. The remote Tomcat must
-support the ajp13 protocol stack. The host name can have a <b>port</b> number
-embedded separated by the colon (':') character.
-</directive>
-
-<directive name="port" default="8009" required="false">
-Port number of the remote Tomcat instance listening for defined protocol requests.
-The default value depends on the worker type. For AJP13 workers the default port is
-<b>8009</b>, while for AJP14 type of worker that value is <b>8011</b>.
-</directive>
-
-<directive name="socket_timeout" default="0" required="false">
-Socket timeout in seconds used for the communication channel between JK and remote host.
-If the remote host does not respond inside the timeout specified, JK will generate an error,
-and retry again. If set to zero (default) JK will wait for an infinite amount of time
-on all socket operations.
-</directive>
-
-<directive name="socket_connect_timeout" default="socket_timeout*1000" required="false">
-Socket connect timeout in milliseconds used for the communication channel between JK and remote host.
-If the remote host does not respond inside the timeout specified, JK will generate an error,
-and retry again.
-<p>
-Note that <code>socket_timeout</code> is in seconds, and
-<code>socket_connect_timeout</code> in milliseconds,
-so in absolute terms the default <code>socket_connect_timeout</code> is
-equal to <code>"socket_timeout</code>.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-<directive name="socket_keepalive" default="False" required="false">
-This directive should be used when you have a firewall between your webserver
-and the Tomcat engine, who tend to drop inactive connections. This flag will tell the Operating System
-to send <code>KEEP_ALIVE</code> messages on inactive connections (interval depend on global OS settings,
-generally 120 minutes), and thus prevent the firewall to cut inactive connections.
-To enable keepalive set this property value to <b>True</b>.
-<p>
-The problem with Firewall cutting inactive connections is that sometimes, neither webserver or Tomcat
-have information about the cut and couldn't handle it.
-</p>
-</directive>
-
-<directive name="ping_mode" default="" required="false">
-This flag determines, under which conditions established
-connections are probed to ensure they are still working.
-The probe is done with an empty AJP13 packet (CPing) and
-expects to receive an appropriate answer (CPong) within
-some timeout.
-<p>
-The value of the flag can be any combination of the following
-flags (multiple values are combined without any separators):
-</p>
-<p><b>C</b> (connect): If set, the connection will
-be probed once after connecting to the backend. The timeout
-can be set by <code>connect_timeout</code>. If it is not set,
-the value of <code>ping_timeout</code> will be used instead.
-</p>
-<p><b>P</b> (prepost): If set, the connection will
-be probed before sending each request to the backend. The timeout
-can be set by <code>prepost_timeout</code>. If it is not set,
-the value of <code>ping_timeout</code> will be used instead.
-</p>
-<p><b>I</b> (interval): If set, the connection will
-be probed during the regular internal maintenance cycle,
-but only if it is idle longer than
-<code>connection_ping_interval</code>. The timeout
-can be set by <code>ping_timeout</code>.
-</p>
-<p><b>A</b> If set, all of the above probes will be used.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.27</b>. Connect and
-prepost probing were already available via <code>connect_timeout</code>
-and <code>prepost_timeout</code> since version <b>jk 1.2.6</b>.
-</p>
-</directive>
-
-<directive name="ping_timeout" default="10000" required="false">
-Timeout in milliseconds used when waiting for the CPong answer of a
-CPing connection probe. The activation of the probes is done via
-<code>ping_mode</code>. The timeouts for <code>ping_mode</code>
-connect and prepost can be overwritten individually via
-<code>connect_timeout</code> and <code>prepost_timeout</code>.
-<p>
-For compatibility reasons, CPing/CPong is also used, whenever
-<code>connect_timeout</code> or <code>prepost_timeout</code> are set,
-even if <code>ping_mode</code> is empty.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-The usage depend on the <code>ping_mode</code> flags used.
-directive <code>connection_ping_interval</code> was not set, the
-value of <code>(ping_timeout/1000) * 10</code> will be used as
-<code>connection_ping_interval</code> value.
-
-<directive name="connection_ping_interval" default="0 / (ping_timeout/1000)*10" required="false">
-When using interval connection probing, connections idle for longer than this
-interval in seconds are probed by CPing packets whether they still work.
-<p>Interval probing can be activated either by <code>ping_mode</code>,
-or by setting <code>connection_ping_interval</code> to some value bigger
-than zero. If you activate interval probing via <code>ping_mode</code>,
-then the default value of <code>connection_ping_interval</code> is
-<code>(ping_timeout/1000) * 10</code>. Note that <code>ping_timeout</code>
-is in milliseconds, and <code>connection_ping_interval</code> in seconds,
-so in absolute terms the default <code>connection_ping_interval</code> is
-10 times <code>ping_timeout</code>.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-<directive name="connection_pool_size" default="see text" required="false">
-This defines the number of connections made to the AJP backend that
-are maintained as a connection pool.
-It will limit the number of those connection that each web server child
-process can made.
-<p>
-Connection pool size property is only used for multi threaded
-web servers such as Apache, IIS and Netscape/Sun. The connection_pool_size property
-needs to reflect the number of requests one web server process should
-be able to send to a backend in parallel. Usually this is the same as
-the number of threads per web server process. JK will discover
-this number for the Apache web server automatically and set the pool size to
-this value. For IIS the default value is 250 (before version 1.2.20: 10),
-for Netscape/Sun the default value is 1.
-</p>
-<p>We strongly recommend adjusting this value for IIS and the Netscape/Sun
-to the number of requests one web server process should
-be able to send to a backend in parallel. You should measure how many connections
-you need during peak activity without performance problems, and then add some
-percentage depending on your growth rate. Finally you should check,
-whether your web server processes are able to use at least as many threads,
-as you configured as the pool size.
-</p>
-<warn>Do not use connection_pool_size with values higher then 1 on <b>Apache 2.x prefork</b> or <b>Apache 1.3.x</b>!</warn>
-</directive>
-
-<directive name="connection_pool_minsize" default="(pool+1)/2" required="false">
-Minimum size of the connection pool that will be maintained.
-<p>
-Its default value is (connection_pool_size+1)/2.
-</p>
-<warn>Do not use connection_pool_size with values higher then 1 on <b>Apache 2.x prefork</b> or <b>Apache 1.3.x</b>!</warn>
-<p>
-This feature has been added in <b>jk 1.2.16</b>.
-</p>
-</directive>
-
-<directive name="connection_pool_timeout" default="0" required="false">
-Cache timeout property should be used with <b>connection_pool_minsize</b> to specify how many seconds JK should keep
-an inactive socket in cache before closing it. This property should be used to reduce the number of threads
-on the Tomcat web server. The default value zero disables the closing (infinite timeout).
-<p>
-Each child could open an ajp13 connection if it has to forward a request to Tomcat, creating
-a new ajp13 thread on Tomcat side.
-</p>
-<p>
-The problem is that after an ajp13 connection is created, the child won't drop it
-until killed. And since the webserver will keep its childs/threads running
-to handle high-load, even it the child/thread handle only static contents, you could
-finish having many unused ajp13 threads on the Tomcat side.
-</p>
-<p>
-You should keep this time interval in sync with the <b>connectionTimeout</b> attribute
-of your AJP connector in Tomcat's server.xml. Note however, that the value
-for mod_jk is given in seconds, the one in server.xml has to use milliseconds.
-</p>
-</directive>
-
-<directive name="connection_acquire_timeout" default="retries*retry_interval" required="false">
-Timeout the worker will wait for a free socket in cache before giving up.
-<p>
-Its default value is <b>retries * retry_interval</b>.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-<directive name="lbfactor" default="1" required="false">
-Only used for a member worker of a load balancer.
-<p>
-The integer number lbfactor (load-balancing factor) is
-<i>how much we expect this worker to work</i>, or
-<i>the worker's work quota</i>. Load balancing factor is compared with other workers
-that makes the load balancer. For example if one worker has lb_factor 5 times higher then
-other worker, then it will receive five times more requests.
-</p>
-</directive>
-
-</directives>
-
-</subsection>
-
-<subsection name="Load Balancing Directives">
-<br/>
-<p>Load balancer is a virtual worker that does not really communicate with Tomcat workers.
-Instead it is responsible for the management of several "real" workers.
-The worker is supposed to be a load balancer if it's worker type is <b>lb</b>.
-See worker's <b>type</b> directive.
-</p>
-<p>Loadbalancer directives define the parameters needed to create the workers that are
-connecting to a remote cluster of backend Tomcat servers. Each cluster node has to
-have a worker defined.
-</p>
-<p>
-Load balancer management includes:
-</p>
-
-<ul>
-<li>
-Instantiating the workers in the web server.
-</li>
-<li>
-Using the worker's load-balancing factor, perform weighed-round-robin load balancing where
-high lbfactor means stronger machine (that is going to handle more requests)
-</li>
-<li>
-Keeping requests belonging to the same session executing on the same Tomcat worker.
-</li>
-<li>
-Identifying failed Tomcat workers, suspending requests to them and instead fall-backing on
-other workers managed by the lb worker.
-</li>
-</ul>
-
-<p>
-The overall result is that workers managed by the same lb worker are load-balanced
-(based on their lbfactor and current user session) and also fall-backed so a single
-Tomcat process death will not "kill" the entire site.
-</p>
-<warn>
-If you want to use session stickiness, you must set different jvmRoute attributes
-in the Engine element in Tomcat's server.xml. Furthermore the names of the workers
-which are managed by the balancer have to be equal to the jvmRoute of the Tomcat
-instance they connect with.
-</warn>
-<p>
-The restriction on the worker names can be lifted, if you use the route attribute for the workers.
-</p>
-<p>
-The following table specifies properties that the lb worker can accept:
-</p>
-
-<directives>
-<directive name="balance_workers" default="" required="true">
-A comma separated list of workers that the load balancer
-need to manage.
-<p>
-This directive can be used multiple times for the same load balancer.
-</p>
-<p>
-This directive replaces old <b>balanced_workers</b> directive and
-can be used only with mod_jk versions 1.2.7 and up.
-</p>
-<warn>As long as these workers should only be used via the load balancer worker,
-there is no need to also put them into the <b>worker.list</b> property.</warn>
-</directive>
-
-<directive name="sticky_session" default="True" required="false">
-Specifies whether requests with SESSION ID's should be routed back to the same
-Tomcat worker. If sticky_session is set to <b>True</b> or <b>1</b> sessions are sticky, otherwise
-sticky_session is set to <b>False</b>. Set sticky_session to <b>False</b> when Tomcat
-is using a Session Manager which can persist session data across multiple
-instances of Tomcat.
-</directive>
-
-<directive name="sticky_session_force" default="False" required="false">
-Specifies whether requests with SESSION ID's for workers that are in error state
-should be rejected. If sticky_session_force is set to <b>True</b> or <b>1</b>
-and the worker that matches that SESSION ID is in error state, client will
-receive 500 (Server Error). If set to <b>False</b> or <b>0</b> failover on
-another worker will be issued with loosing client session. This directive is
-used only when you set <b>sticky_session=True</b>.
-<p>
-This feature has been added in <b>jk 1.2.9</b>.
-</p>
-</directive>
-
-<directive name="method" default="Request" required="false">
-Specifies what method load balancer is using for electing the best worker.
-Please note, that session stickiness and perfect load balancing are
-conflicting targets, especially when the number
-of sessions is small, or the usage of sessions is extremely varying
-For huge numbers of sessions this usually is not a problem.
-<p>
-Some methods note, that they aggregate in a sliding time window. They add up
-accesses, and on each run of the global maintain method, the load counters
-get divided by 2. Usually this happens once a minute, depending on the
-setting of worker.maintain. The value of the load counters can be inspected
-using the status worker.
-</p>
-<p>
-If method is set to <b>R[equest]</b> the balancer will use number of requests
-to find the best worker. Accesses will be distributed according to the
-lbfactor in a sliding time window. This is the default value and should be
-working well for most applications.
-</p>
-<p>
-If method is set to <b>S[ession]</b> the balancer will use number of sessions
-to find the best worker. Accesses will be distributed according to the
-lbfactor in a sliding time window. Because the balancer does not keep any state,
-it actually does not know the number of sessions. Instead it counts each request
-without a session cookie or URL encoding as a new session. This method will neither
-know, when a session is being invalidated, nor will it correct its load numbers
-according to session timeouts or worker failover. This method should be used,
-if sessions are your limiting resource, e.g. when you only have limited memory
-and your sessions need a lot of memory.
-</p>
-<p>
-If set to <b>T[raffic]</b> the balancer will use
-the network traffic between JK and Tomcat to find the best worker.
-Accesses will be distributed according to the lbfactor in a sliding time window.
-This method should be used, if network to and from the backends is your
-limiting resource.
-</p>
-<p>
-If set to <b>B[usyness]</b> the balancer will
-pick the worker with the lowest current load, based on how many requests the
-worker is currently serving. This number is divided by the workers lbfactor,
-and the lowest value (least busy) worker is picked. This method is especially
-interesting, if your request take a long time to process, like for a download
-application.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.9</b>.
-The Session method has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-
-<directive name="lock" default="Optimistic" required="false">
-Specifies what lock method the load balancer will use for synchronising
-shared memory runtime data.
-If lock is set to <b>O[ptimistic]</b> balancer will not use shared memory lock
-to find the best worker. If set to <b>P[essimistic]</b> balancer will use
-shared memory lock. The balancer will work more accurately in case of
-Pessimistic locking, but can slow down the average response time.
-<p>
-This feature has been added in <b>jk 1.2.13</b>.
-</p>
-</directive>
-
-<directive name="retries" default="2" required="false">
-<warn>This directive also exists for normal workers.
-For those it has a <a href="#Advanced Worker Directives">different meaning</a>.</warn>
-If the load balancer can not get a valid member worker or in case of failover,
-it will try again a number of times given by <b>retries</b>.
-Before each retry, it will make a pause define by <b>retry_interval</b> directive.
-<p>
-Until version <b>1.2.16</b> the default value was 3.
-</p>
-</directive>
-
-</directives>
-
-</subsection>
-
-<subsection name="Status Worker Directives">
-<br />
-<p>
-The status worker does not communicate with Tomcat.
-Instead it is responsible for the load balancer management.
-</p>
-<directives>
-<directive name="css" default="" required="false">
-Specifies the url for cascading stylesheet to use.
-</directive>
-<directive name="read_only" default="False" required="false">
-A status worker with read_only=True will not allow any operations,
-that change the runtime state or configuration of the other workers.
-These are edit/update/reset/recover.
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="user" default="" required="false">
-It is a list of users
-which gets compared to the user name authenticated by the web server.
-If the name is not contained in this list, access is denied. Per
-default the list is empty and then access is allowed to anybody.
-<p>
-This directive can be used multiple times.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="user_case_insensitive" default="False" required="false">
-By default, the user names are matched case sensitively. You can set
-user_case_insensitive=True to make the comparison case insensitive.
-This may be especially useful on the Windows platform.
-<p>
-This feature has been added in <b>jk 1.2.21</b>.
-</p>
-</directive>
-<directive name="good" default="a.o,a.n,a.b,a.r" required="false">
-For every load balancer worker, the status worker shows a summary
-of the state of its members. There are three such states,
-"good", "bad" and "degraded".
-<p>
-These states are determined depending on the activation of the members
-(active, disabled, stopped) and their runtime state
-(ok, n/a, busy, recovering, probing, forced recovery, error).
-By default, members are assumed to be "good", if their activation
-is "active" and their runtime state is not "error".
-</p>
-<p>
-You can change this mapping, by assigning a list of values to the
-attribute "good". Each value gives a possible match for the members,
-and one match suffices. Each value is either a single character, or two
-characters combined with a dot ".". The single characters are the
-first characters in the words "active", "disabled", "stopped",
-"ok", "na", "busy", "recovering", "error". The additional states "probing"
-and "forced recovery" are always rated equivalent to "recovering".
-If a value consists only
-of a single character, then all members with this activation or runtime
-state will be assumed good. A combination of an activation and a runtime
-state concatenated with a dot "." does only apply to a member, that has
-exactly this activation and state.
-</p>
-<p>
-Members of a load balancer will first be matched against the state "bad",
-if they don't match, the state "good" will be tried, and if they
-still don't match, their state will be "degraded".
-</p>
-<p>
-This directive can be used multiple times.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="bad" default="s,e" required="false">
-See: "good".
-<p>
-By default, members are assumed to be "bad", if their activation
-is "stopped" or their runtime state is "error".
-</p>
-<p>
-This directive can be used multiple times.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="prefix" default="worker" required="false">
-The prefix, which will be used by the status worker
-when producing properties output (mime=prop).
-Each property key will be prefixed by this value.
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="ns" default="jk:" required="false">
-This directive can be used to customise the XML output from the
-status worker. If set to <b>-</b> no namespace will be used.
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="xmlns" default="" required="false">
-This directive can be used to customise the XML output from the
-status worker. If set to <b>-</b> no xmlns will be used.
-<p>
-Default value is set to xmlns:jk=&quot;http://tomcat.apache.org&quot;
-</p>
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-<directive name="doctype" default="" required="false">
-This directive can be used to customise the XML output from the
-status worker. This value will be inserted to the output xml
-after the xml header.
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-</directive>
-
-</directives>
-</subsection>
-
-<subsection name="Advanced Worker Directives">
-<br />
-<p>
-This table lists more advanced configuration options. Most of them only apply to
-some types of workers. We use the abbreviations <b>AJP</b> for ajp13/ajp14 workers
-used directly via the workers.list, <b>LB</b> for load balancer workers,
-and <b>SUB</b> for the workers used indirectly in a load balancer worker
-as a sub worker or member.
-</p>
-<advanceddirectives>
-<directive name="connect_timeout" workers="AJP,SUB" default="0" required="false">
-Connect timeout property told webserver to send a PING request on ajp13 connection after
-connection is established. The parameter is the delay in milliseconds to wait for the PONG reply.
-The default value zero disables the timeout (infinite timeout).
-<p>
-This features has been added in <b>jk 1.2.6</b> to avoid problem with hung Tomcat's and require ajp13
-ping/pong support which has been implemented on Tomcat <b>3.3.2+, 4.1.28+ and 5.0.13+</b>.
-Disabled by default.
-</p>
-</directive>
-
-<directive name="prepost_timeout" workers="AJP,SUB" default="0" required="false">
-Prepost timeout property told webserver to send a PING request on ajp13 connection before
-forwarding to it a request. The parameter is the delay in milliseconds to wait for the PONG reply.
-The default value zero disables the timeout (infinite timeout).
-<p>
-This features has been added in <b>jk 1.2.6</b> to avoid problem with hung Tomcat's and require ajp13
-ping/pong support which has been implemented on <b>Tomcat 3.3.2+, 4.1.28+ and 5.0.13+</b>.
-Disabled by default.
-</p>
-</directive>
-
-<directive name="reply_timeout" workers="AJP,SUB" default="0" required="false">
-The parameter is the number of milliseconds to wait for success during a read event.
-So this is not a timeout for the complete answer time of a request, but only
-for the maximum time between two packets received from Tomcat. Usually the longest
-pause is between sending the request and getting the first packet of the response.
-<p>
-If the timeout passes without any data received from Tomcat, the webserver will
-no longer wait for the rest of the response and send an error to the client (browser).
-Usually this does not mean, that the request is also aborted on the Tomcat backend.
-If the worker is a member of a load balancer, the load balancer might place the
-worker into an error state and retry the request on another member.
-See also <b>max_reply_timeouts</b>, <b>retries</b> and <b>recovery_options</b>.
-</p>
-<p>
-By default (value zero) the webserver will wait forever which could be an issue for you.
-If you set a reply_timeout, adjust it carefully if you have long running servlets.
-</p>
-<p>
-The reply_timeout can be overwritten using the Apache httpd environment variable
-JK_REPLY_TIMEOUT.
-</p>
-<p>
-This features has been added in <b>jk 1.2.6</b> to avoid problem with hung Tomcat's and works on all
-servlet engines supporting ajp13. The variable JK_REPLY_TIMEOUT has been added in version <b>1.2.27</b>.
-</p>
-</directive>
-
-<directive name="retries" workers="AJP,SUB" default="2" required="false">
-<warn>This directive also exists for load balancer workers.
-For those it has a <a href="#Load Balancing Directives">different meaning</a>.</warn>
-The maximum number of times that the worker will send a request to Tomcat
-in case of a communication error. Each retry will be done over another
-connection. The first time already gets counted, so retries=2 means
-one retry after error. Before a retry, the worker waits for a configurable
-sleeping time.
-<p>
-See also the attribute <b>recovery_options</b> for a more fine-grained control
-of retries and <b>retry_interval</b> for the sleep time configuration.
-</p>
-<p>
-Until version <b>1.2.16</b> the default value was 3.
-</p>
-</directive>
-
-<directive name="retry_interval" workers="AJP,SUB" default="100" required="false">
-The amount of time in milliseconds the worker sleeps before doing any retry.
-<p>
-This features has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-<directive name="recovery_options" workers="AJP,SUB" default="0" required="false">
-Recovery options influence, how we should handle retries,
-in case we detect a problem with Tomcat.
-How often we will retry is controlled by the attribute <b>retries</b>.
-<p>
-This attribute is a bit mask. The following bits are allowed:<br/>
-1: don't recover if Tomcat failed after getting the request<br/>
-2: don't recover if Tomcat failed after sending the headers to client<br/>
-4: close the connection to Tomcat, if we detect an error when writing back
-the answer to the client (browser)<br/>
-8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are set)<br/>
-16: always recover requests for HTTP method GET (even if Bits 1 or 2 are set)<br/>
-</p>
-<p>
-This features has been added in <b>jk 1.2.6</b>.
-Option 4 has been added in version <b>1.2.16</b>,
-options 8 and 16 in version <b>1.2.24</b>.
-</p>
-</directive>
-
-<directive name="fail_on_status" workers="AJP,SUB" default="0" required="false">
-Set this value to the HTTP status code that will cause a worker to fail
-if returned from Servlet container. Use this directive to deal with
-cases when the servlet container can temporary return non-200 responses
-for a short amount of time, e.g during redeployment.
-<p>
-The error page, headers and status codes of the original response will not be send back
-to the client. Instead the request will result in a 503 response.
-If the worker is a member of a load balancer, the member will
-be put into an error state. Request failover and worker recovery will be handled
-with the usual load balancer procedures.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.20</b>.
-</p>
-<p>
-Starting with <b>jk 1.2.22</b> it is possible to define multiple
-status codes separated by space or comma characters.
-For example: <code>worker.xxx.fail_on_status=500,503</code>
-</p>
-<p>
-Starting with <b>jk 1.2.25</b> you can also tell the load
-balancer to not put a member into an error state, if a
-response returned with one of the status codes in
-fail_on_status. This feature gets enabled, by putting a minus sign in
-front of those status codes.
-For example: <code>worker.xxx.fail_on_status=-404,-500,503</code>
-</p>
-</directive>
-
-<directive name="max_packet_size" workers="AJP,SUB" default="8192" required="false">
-This attribute sets the maximal AJP packet size in Bytes.
-The maximum value is 65536. If you change it from the default,
-you <b>must</b> also change the packetSize attribute of your AJP
-connector on the Tomcat side! The attribute packetSize is only available
-in Tomcat 5.5.20+ and 6.0.2+.
-<p>
-Normally it is not necessary to change the maximum packet size. Problems
-with the default value have been reported when sending certificates or
-certificate chains.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.19</b>.
-</p>
-</directive>
-
-<directive name="mount" workers="AJP,LB" default="" required="false">
-Space delimited list of uri maps the worker should handle. It is only used,
-if the worker is included in worker.list.
-<p>
-This directive can be used multiple times for the same worker.
-</p>
-</directive>
-
-<directive name="secret" workers="AJP,LB,SUB" default="" required="false">
-You can set a secret keyword on the Tomcat AJP Connector. Then only requests
-from workers with the same secret keyword will be accepted.
-<p>
-Use <b>request.secret="secret key word"</b> in your Tomcat AJP Connector configuration.
-</p>
-<p>
-If you set a secret on a load balancer, all its members will inherit this secret.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.12</b>.
-</p>
-</directive>
-
-<directive name="max_reply_timeouts" workers="LB" default="0" required="false">
-If you use a <b>reply_timeout</b> for the members of a load balancer worker,
-and you want to tolerate a few requests taking longer than reply_timeout,
-you can set this attribute to some positive value.
-<p>
-Long running requests will still time out after reply_timeout milliseconds waiting for
-data, but the corresponding member worker will only be put into an error state,
-if more than <b>max_reply_timeouts</b> requests have timed out.
-More precisely, the counter for those bad requests will be divided by two,
-whenever the load balancer does its internal maintenance (by default every 60
-seconds).
-</p>
-<p>
-This features has been added in <b>jk 1.2.24</b> to make <b>reply_timeout</b> less
-sensitive for sporadic long running requests.
-</p>
-</directive>
-
-<directive name="recover_time" workers="LB" default="60" required="false">
-The recover time is the time in seconds the load balancer will not try
-to use a worker, after it went into error state. Only after this time has passed,
-a worker in error state will be marked as in recovering, so that it will be
-tried for new requests.
-<p>
-This interval is not checked every time a request is being processed.
-Instead it is being checked during global maintenance. The time between two
-runs of global maintenance is controlled by worker.maintain.
-</p>
-<p>
-Do not set recover_time to a very short time unless you understand the implications.
-Every recovery attempt for a worker in error is done by a real request!
-</p>
-</directive>
-
-<directive name="error_escalation_time" workers="LB" default="recover_time / 2" required="false">
-Setting a member of a load balancer into an error state is quite serious. E.g.
-it means that if you need stickyness, all access to the sessions of the
-respective node is blocked.
-<p>
-Some types of error detection do not provide a precise information, whether
-a node is completely broken or not. In those cases an LB will not immediately
-put the node into the error state. Only when there have been no successful
-responses for <b>error_escalation_time</b> seconds after such an error,
-will the node be put into error state.
-</p>
-<p>
-This features has been added in <b>jk 1.2.28</b>.
-</p>
-</directive>
-
-<directive name="activation" workers="SUB" default="Active" required="false">
-Using this directive, a balanced worker of a load balancer
-can be configured as disabled or stopped. A disabled worker only gets
-requests, which belong to sessions for that worker. A stopped
-worker does not get any requests. Users of a stopped worker will
-loose their sessions, unless session replication via clustering is used.
-<p>
-Use <b>d</b> or <b>D</b> to disable and <b>s</b> or <b>S</b> to stop.
-If this directive is not present the deprecated directives
-"disabled" or "stopped" are used.
-</p>
-<p>
-This flag can be changed at runtime using status worker.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.19</b>.
-</p>
-</directive>
-
-<directive name="route" workers="SUB" default="worker name" required="false">
-Normally the name of a balanced worker in a load balancer is equal to the jvmRoute
-of the corresponding Tomcat instance. If you want to include a worker corresponding
-to a Tomcat instance into several load balancers with different balancing configuration
-(e.g. disabled, stopped) you can use this attribute.
-<p>
-Define a separate worker per lb and per Tomcat instance with an arbitrary worker name and 
-set the route attribute of the worker equal to the jvmRoute of the target Tomcat instance.
-</p>
-<p>
-If this attribute is left empty, the name of the worker will be used.
-</p>
-<p>
-This attribute can be changed at runtime using status worker.
-</p>
-<p>
-If the route name contains a period, the part before the first period will be
-used as domain name, unless domain is set explicitly.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.16</b>.<br/>
-The automatic domain rule has been added in <b>jk 1.2.20</b>.<br/>
-The attribute has been renamed from jvm_route to route in <b>jk 1.2.20</b>.
-</p>
-</directive>
-
-<directive name="distance" workers="SUB" default="0" required="false">
-An integer number to express preferences between
-the balanced workers of an lb worker.
-A load balancer will never choose some balanced worker 
-in case there is another usable worker with lower distance.
-<p>
-Only in case all workers below a given distance are in error, disabled or stopped,
-workers of a larger distance are eligible for balancing.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.16</b>.
-</p>
-</directive>
-
-<directive name="domain" workers="SUB" default="" required="false">
-Domain directive can be used only when the worker is a member of the load balancer.
-Workers that share the same domain name are treated as single worker. If sticky_session
-is used, then the domain name is used as session route.
-<p>
-This directive is used for large system with more then 6 Tomcats, to be able
-to cluster the Tomcats in two groups and thus lowering the session replication
-transfer between them.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.8</b>.
-</p>
-</directive>
-
-<directive name="redirect" workers="SUB" default="" required="false">
-Set to the name of the preferred failover worker. If worker matching
-SESSION ID is in error state then the redirect worker will be used instead.
-It will be used even if being disabled, thus offering hot standby.
-<p>
-If you explicitly set a route via the "route" attribute, you must set "redirect"
-to this route of the preferred failover worker and not to its name.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.9</b>.
-</p>
-</directive>
-
-<directive name="session_cookie" workers="LB" default="JSESSIONID" required="false">
-The name of the cookie that contains the routing identifier needed for session stickyness.
-The routing identifier is everything after a "." character in the value of the cookie.
-<p>
-This feature has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-<directive name="session_path" workers="LB" default=";jsessionid" required="false">
-The name of the path parameter that contains the routing identifier needed for
-session stickyness. The routing identifier is everything after a "." character in the value
-of the path parameter.
-<p>
-This feature has been added in <b>jk 1.2.27</b>.
-</p>
-</directive>
-
-</advanceddirectives>
-</subsection>
-
-<subsection name="Deprecated Worker Directives">
-<br/>
-<p>The following directives have been deprecated in the past. We include their documentation
-in case you need to use an older version of mod_jk. We urge you to update and not use
-them any more. Please migrate your existing configurations.
-</p>
-<deprecations>
-<directive name="cachesize" successor="connection_pool_size" default="see text" required="false">
-<warn>This directive has been deprecated since 1.2.16.</warn>
-Cachesize defines the number of connections made to the AJP backend that
-are maintained as a connection pool.
-It will limit the number of those connection that each web server child
-process can make.
-<p>
-Cachesize property is used only for multi threaded 
-web servers such as Apache 2.0 (worker), IIS and Netscape. The cachesize property
-should reflect the number of threads per child process. JK will discover
-the number of threads per child process on Apache 2 web server with worker-mpm and set
-its default value to match the ThreadsPerChild Apache directive. For IIS the default
-value is 10. For other web servers than Apache or IIS this value has to be set manually.
-</p>
-<warn>Do not use cachesize with values higher then 1 on <b>Apache 2.x prefork</b> or <b>Apache 1.3.x</b>!</warn>
-</directive>
-
-<directive name="cache_timeout" successor="connection_pool_timeout" default="0" required="false">
-<warn>This directive has been deprecated since 1.2.16.</warn>
-Cache timeout property should be used with <b>cachesize</b> to specify how to time JK should keep
-an open socket in cache before closing it. This property should be used to reduce the number of threads 
-on the Tomcat web server.
-<p> 
-Each child could open an ajp13 connection if it have to forward a request to Tomcat, creating
-a new ajp13 thread on Tomcat side.
-</p>
-<p>
-The problem is that after an ajp13 connection is created, the child won't drop it
-until killed. And since the webserver will keep its childs/threads running
-to handle high-load, even it the child/thread handle only static contents, you could
-finish having many unused ajp13 threads on the Tomcat side.
-</p>
-</directive>
-
-<directive name="recycle_timeout" successor="connection_pool_timeout" default="0" required="false">
-<warn>This directive has been deprecated since 1.2.16.</warn>
-The number of seconds that told webserver to cut an ajp13 connection after some time of 
-inactivity. When choosing an endpoint for a request and the assigned socket is open, it will be
-closed if it was not used for the configured time.
-It's a good way to ensure that there won't too old threads living on Tomcat side, 
-with the extra cost you need to reopen the socket next time a request be forwarded.
-This property is very similar to <b>cache_timeout</b> but works also in non-cache mode.
-If set to value zero (default) no recycle will took place. 
-</directive>
-
-<directive name="balanced_workers" successor="balance_workers" default="" required="true">
-<warn>This directive has been deprecated since 1.2.7.</warn>
-A comma separated list of workers that the load balancer
-need to manage.
-</directive>
-
-<directive name="disabled" successor="activation" default="False" required="false">
-<warn>This directive has been deprecated since 1.2.19.</warn>
-If set to <b>True</b> or <b>1</b> the worker will be disabled if member
-of load balancer. This flag can be changed at runtime using status worker.
-<p>
-This feature has been added in <b>jk 1.2.9</b>.
-</p>
-</directive>
-
-<directive name="stopped" successor="activation" default="False" required="false">
-<warn>This directive has been deprecated since 1.2.19.</warn>
-If set to <b>True</b> or <b>1</b> the worker will be stopped if member
-of load balancer. The flag is needed for stop complete traffic of a sticky session
-worker. It is only useful, when you have a cluster that replicated the sessions.
-This flag can be changed at runtime using status worker.
-<p>
-This feature has been added in <b>jk 1.2.11</b>.
-</p>
-</directive>
-
-<directive name="jvm_route" successor="route" default="worker name" required="false">
-<warn>This directive has been deprecated since 1.2.20.</warn>
-Normally the name of a balanced worker in a load balancer is equal to the jvmRoute
-of the corresponding Tomcat instance. If you want to include a worker corresponding
-to a Tomcat instance into several load balancers with different balancing configuration
-(e.g. disabled, stopped) you can use this attribute.
-<p>
-Define a separate worker per lb and per Tomcat instance with an arbitrary worker name and 
-set the jvm_route attribute of the worker equal to the jvmRoute of the target Tomcat instance.
-</p>
-<p>
-If this attribute is left empty, the name of the worker will be used.
-</p>
-<p>
-This attribute can be changed at runtime using status worker.
-</p>
-<p>
-This feature has been added in <b>jk 1.2.16</b>.
-</p>
-</directive>
-
-</deprecations>
-</subsection>
-
-</section>
-
-</body>
-</document>
author	hongbotian <hongbo.tianhongbo@huawei.com>	2015-11-30 03:10:21 -0500
committer	hongbotian <hongbo.tianhongbo@huawei.com>	2015-11-30 03:10:21 -0500
commit	c0b7206652b2852bc574694e7ba07ba1c2acdc00 (patch)
tree	5cb95cb0e19e03610525903df46279df2c3b7eb1 /rubbos/app/tomcat-connectors-1.2.32-src/xdocs/reference/workers.xml
parent	b6d3d6e668b793220f2d3af1bc3e828553dc3fe6 (diff)