workers.properties configuration

-
- -
-

Mandatory directives are the one that each worker must contain. Without them the worker will -be unavailable or will misbehave. Those directives will be marked with a strong font in the following tables. -

- - -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. -

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 -AJPv13 protocol specification -

-JNI workers have been deprecated. They will likely not work. Do not use them. - - - - - -
-

Connection directives defines the parameters needed to connect and maintain -the connections pool of persistent connections between JK and remote Tomcat. -

- - - -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 port number -embedded separated by the colon (':') character. - - - -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 -8009, while for AJP14 type of worker that value is 8011. - - - -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. - - - -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. -

-Note that socket_timeout is in seconds, and -socket_connect_timeout in milliseconds, -so in absolute terms the default socket_connect_timeout is -equal to "socket_timeout. -

-This feature has been added in jk 1.2.27. -

- - - -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 KEEP_ALIVE 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 True. -

-The problem with Firewall cutting inactive connections is that sometimes, neither webserver or Tomcat -have information about the cut and couldn't handle it. -

- - - -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. -

-The value of the flag can be any combination of the following -flags (multiple values are combined without any separators): -

C (connect): If set, the connection will -be probed once after connecting to the backend. The timeout -can be set by connect_timeout. If it is not set, -the value of ping_timeout will be used instead. -

P (prepost): If set, the connection will -be probed before sending each request to the backend. The timeout -can be set by prepost_timeout. If it is not set, -the value of ping_timeout will be used instead. -

I (interval): If set, the connection will -be probed during the regular internal maintenance cycle, -but only if it is idle longer than -connection_ping_interval. The timeout -can be set by ping_timeout. -

A If set, all of the above probes will be used. -

-This feature has been added in jk 1.2.27. Connect and -prepost probing were already available via connect_timeout -and prepost_timeout since version jk 1.2.6. -

- - - -Timeout in milliseconds used when waiting for the CPong answer of a -CPing connection probe. The activation of the probes is done via -ping_mode. The timeouts for ping_mode -connect and prepost can be overwritten individually via -connect_timeout and prepost_timeout. -

-For compatibility reasons, CPing/CPong is also used, whenever -connect_timeout or prepost_timeout are set, -even if ping_mode is empty. -

-This feature has been added in jk 1.2.27. -

- - -The usage depend on the ping_mode flags used. -directive connection_ping_interval was not set, the -value of (ping_timeout/1000) * 10 will be used as -connection_ping_interval value. - - -When using interval connection probing, connections idle for longer than this -interval in seconds are probed by CPing packets whether they still work. -

Interval probing can be activated either by ping_mode, -or by setting connection_ping_interval to some value bigger -than zero. If you activate interval probing via ping_mode, -then the default value of connection_ping_interval is -(ping_timeout/1000) * 10. Note that ping_timeout -is in milliseconds, and connection_ping_interval in seconds, -so in absolute terms the default connection_ping_interval is -10 times ping_timeout. -

-This feature has been added in jk 1.2.27. -

- - - -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. -

-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. -

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. -

-Do not use connection_pool_size with values higher then 1 on Apache 2.x prefork or Apache 1.3.x! - - - -Minimum size of the connection pool that will be maintained. -

-Its default value is (connection_pool_size+1)/2. -

-Do not use connection_pool_size with values higher then 1 on Apache 2.x prefork or Apache 1.3.x! -

-This feature has been added in jk 1.2.16. -

- - - -Cache timeout property should be used with connection_pool_minsize 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). -

-Each child could open an ajp13 connection if it has to forward a request to Tomcat, creating -a new ajp13 thread on Tomcat side. -

-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. -

-You should keep this time interval in sync with the connectionTimeout 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. -

- - - -Timeout the worker will wait for a free socket in cache before giving up. -

-Its default value is retries * retry_interval. -

-This feature has been added in jk 1.2.27. -

- - - -Only used for a member worker of a load balancer. -

-The integer number lbfactor (load-balancing factor) is -how much we expect this worker to work, or -the worker's work quota. 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. -

- - - - - - - -
-

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 lb. -See worker's type directive. -

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. -

-Load balancer management includes: -

- -

-Instantiating the workers in the web server. -
-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) -
-Keeping requests belonging to the same session executing on the same Tomcat worker. -
-Identifying failed Tomcat workers, suspending requests to them and instead fall-backing on -other workers managed by the lb worker. -

- -

-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. -

- -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. - -

-The restriction on the worker names can be lifted, if you use the route attribute for the workers. -

-The following table specifies properties that the lb worker can accept: -

- - - -A comma separated list of workers that the load balancer -need to manage. -

-This directive can be used multiple times for the same load balancer. -

-This directive replaces old balanced_workers directive and -can be used only with mod_jk versions 1.2.7 and up. -

-As long as these workers should only be used via the load balancer worker, -there is no need to also put them into the worker.list property. - - - -Specifies whether requests with SESSION ID's should be routed back to the same -Tomcat worker. If sticky_session is set to True or 1 sessions are sticky, otherwise -sticky_session is set to False. Set sticky_session to False when Tomcat -is using a Session Manager which can persist session data across multiple -instances of Tomcat. - - - -Specifies whether requests with SESSION ID's for workers that are in error state -should be rejected. If sticky_session_force is set to True or 1 -and the worker that matches that SESSION ID is in error state, client will -receive 500 (Server Error). If set to False or 0 failover on -another worker will be issued with loosing client session. This directive is -used only when you set sticky_session=True. -

-This feature has been added in jk 1.2.9. -

- - - -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. -

-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. -

-If method is set to R[equest] 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. -

-If method is set to S[ession] 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. -

-If set to T[raffic] 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. -

-If set to B[usyness] 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. -

-This feature has been added in jk 1.2.9. -The Session method has been added in jk 1.2.20. -

- - - -Specifies what lock method the load balancer will use for synchronising -shared memory runtime data. -If lock is set to O[ptimistic] balancer will not use shared memory lock -to find the best worker. If set to P[essimistic] 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. -

-This feature has been added in jk 1.2.13. -

- - - -This directive also exists for normal workers. -For those it has a different meaning. -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 retries. -Before each retry, it will make a pause define by retry_interval directive. -

-Until version 1.2.16 the default value was 3. -

- - - - - - - -
-

-The status worker does not communicate with Tomcat. -Instead it is responsible for the load balancer management. -

- - -Specifies the url for cascading stylesheet to use. - - -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. -

-This feature has been added in jk 1.2.20. -

- - -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. -

-This directive can be used multiple times. -

-This feature has been added in jk 1.2.20. -

- - -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. -

-This feature has been added in jk 1.2.21. -

- - -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". -

-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". -

-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. -

-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". -

-This directive can be used multiple times. -

-This feature has been added in jk 1.2.20. -

- - -See: "good". -

-By default, members are assumed to be "bad", if their activation -is "stopped" or their runtime state is "error". -

-This directive can be used multiple times. -

-This feature has been added in jk 1.2.20. -

- - -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. -

-This feature has been added in jk 1.2.20. -

- - -This directive can be used to customise the XML output from the -status worker. If set to - no namespace will be used. -

-This feature has been added in jk 1.2.20. -

- - -This directive can be used to customise the XML output from the -status worker. If set to - no xmlns will be used. -

-Default value is set to xmlns:jk="http://tomcat.apache.org" -

-This feature has been added in jk 1.2.20. -

- - -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. -

-This feature has been added in jk 1.2.20. -

- - - - - - -
-

-This table lists more advanced configuration options. Most of them only apply to -some types of workers. We use the abbreviations AJP for ajp13/ajp14 workers -used directly via the workers.list, LB for load balancer workers, -and SUB for the workers used indirectly in a load balancer worker -as a sub worker or member. -

- - -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). -

-This features has been added in jk 1.2.6 to avoid problem with hung Tomcat's and require ajp13 -ping/pong support which has been implemented on Tomcat 3.3.2+, 4.1.28+ and 5.0.13+. -Disabled by default. -

- - - -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). -

-This features has been added in jk 1.2.6 to avoid problem with hung Tomcat's and require ajp13 -ping/pong support which has been implemented on Tomcat 3.3.2+, 4.1.28+ and 5.0.13+. -Disabled by default. -

- - - -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. -

-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 max_reply_timeouts, retries and recovery_options. -

-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. -

-The reply_timeout can be overwritten using the Apache httpd environment variable -JK_REPLY_TIMEOUT. -

-This features has been added in jk 1.2.6 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 1.2.27. -

- - - -This directive also exists for load balancer workers. -For those it has a different meaning. -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. -

-See also the attribute recovery_options for a more fine-grained control -of retries and retry_interval for the sleep time configuration. -

-Until version 1.2.16 the default value was 3. -

- - - -The amount of time in milliseconds the worker sleeps before doing any retry. -

-This features has been added in jk 1.2.27. -

- - - -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 retries. -

-This attribute is a bit mask. The following bits are allowed:
-1: don't recover if Tomcat failed after getting the request
-2: don't recover if Tomcat failed after sending the headers to client
-4: close the connection to Tomcat, if we detect an error when writing back -the answer to the client (browser)
-8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are set)
-16: always recover requests for HTTP method GET (even if Bits 1 or 2 are set)
-

-This features has been added in jk 1.2.6. -Option 4 has been added in version 1.2.16, -options 8 and 16 in version 1.2.24. -

- - - -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. -

-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. -

-This feature has been added in jk 1.2.20. -

-Starting with jk 1.2.22 it is possible to define multiple -status codes separated by space or comma characters. -For example: worker.xxx.fail_on_status=500,503 -

-Starting with jk 1.2.25 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: worker.xxx.fail_on_status=-404,-500,503 -

- - - -This attribute sets the maximal AJP packet size in Bytes. -The maximum value is 65536. If you change it from the default, -you must 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+. -

-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. -

-This feature has been added in jk 1.2.19. -

- - - -Space delimited list of uri maps the worker should handle. It is only used, -if the worker is included in worker.list. -

-This directive can be used multiple times for the same worker. -

- - - -You can set a secret keyword on the Tomcat AJP Connector. Then only requests -from workers with the same secret keyword will be accepted. -

-Use request.secret="secret key word" in your Tomcat AJP Connector configuration. -

-If you set a secret on a load balancer, all its members will inherit this secret. -

-This feature has been added in jk 1.2.12. -

- - - -If you use a reply_timeout 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. -

-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 max_reply_timeouts 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). -

-This features has been added in jk 1.2.24 to make reply_timeout less -sensitive for sporadic long running requests. -

- - - -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. -

-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. -

-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! -

- - - -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. -

-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 error_escalation_time seconds after such an error, -will the node be put into error state. -

-This features has been added in jk 1.2.28. -

- - - -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. -

-Use d or D to disable and s or S to stop. -If this directive is not present the deprecated directives -"disabled" or "stopped" are used. -

-This flag can be changed at runtime using status worker. -

-This feature has been added in jk 1.2.19. -

- - - -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. -

-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. -

-If this attribute is left empty, the name of the worker will be used. -

-This attribute can be changed at runtime using status worker. -

-If the route name contains a period, the part before the first period will be -used as domain name, unless domain is set explicitly. -

-This feature has been added in jk 1.2.16.
-The automatic domain rule has been added in jk 1.2.20.
-The attribute has been renamed from jvm_route to route in jk 1.2.20. -

- - - -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. -

-Only in case all workers below a given distance are in error, disabled or stopped, -workers of a larger distance are eligible for balancing. -

-This feature has been added in jk 1.2.16. -

- - - -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. -

-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. -

-This feature has been added in jk 1.2.8. -

- - - -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. -

-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. -

-This feature has been added in jk 1.2.9. -

- - - -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. -

-This feature has been added in jk 1.2.27. -

- - - -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. -

-This feature has been added in jk 1.2.27. -

- - - - - - -
-

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. -

- - -This directive has been deprecated since 1.2.16. -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. -

-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. -

-Do not use cachesize with values higher then 1 on Apache 2.x prefork or Apache 1.3.x! - - - -This directive has been deprecated since 1.2.16. -Cache timeout property should be used with cachesize 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. -

-Each child could open an ajp13 connection if it have to forward a request to Tomcat, creating -a new ajp13 thread on Tomcat side. -

- - - -This directive has been deprecated since 1.2.16. -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 cache_timeout but works also in non-cache mode. -If set to value zero (default) no recycle will took place. - - - -This directive has been deprecated since 1.2.7. -A comma separated list of workers that the load balancer -need to manage. - - - -This directive has been deprecated since 1.2.19. -If set to True or 1 the worker will be disabled if member -of load balancer. This flag can be changed at runtime using status worker. -

-This feature has been added in jk 1.2.9. -

- - - -This directive has been deprecated since 1.2.19. -If set to True or 1 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. -

-This feature has been added in jk 1.2.11. -

- - - -This directive has been deprecated since 1.2.20. -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. -

-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. -

-If this attribute is left empty, the name of the worker will be used. -

-This attribute can be changed at runtime using status worker. -

-This feature has been added in jk 1.2.16. -

- - - - - -