Each Tomcatworker is a Tomcat instance that serves webserver and waits for servlet fulfillment. For example, we often use webservers such as Apache to forward sevlet requests to a Tomcat process (that is, the worker mentioned above) located behind it ). This article describes how to configure various types of worker and loadbalance, and
I. INTRODUCTION:
Each Tomcat worker is a Tomcat instance that serves the web server and waits for servlet fulfillment. For example, we often use web servers like Apache to forward sevlet requests to a Tomcat process (that is, the worker mentioned above) located behind it ). This article describes how to configure various types of worker and loadbalance, and clarifies the features of various types of worker and the principles of loadbalance configuration.
II. why Tomcat workers:
The above describes a very simple structure. In fact, multiple Tomcat workers can be configured to handle servlet requests forwarded by the web server. The reason for such configuration is nothing more than the following hypothetical environments:
* In the development environment, we announce that different Tomcat workers serve different exploitation services. Of course, developers in the development environment share the same web server, but each Tomcat worke serves its developers.
* We define their respective virtual hosts in different Tomcat processes, so that different companies can apply their respective web sites so that their web sites can be fairly separated.
* We provide the load balancing web site, which means that multiple Tomcat workers are applied at the same time, and each Tomcat worker has an independent host, and the workers must be allocated with requests forwarded by web server.
Of course, these hypothetical situations may not cover all the statuses of multiple workers.
III. workers. properties configuration clarification:
To define Tomcat workers, compile an attribute file named "workers. properties" in the conf directory of apache. This article describes how to configure:
1. define the Workers list:
The workers definition method is to compile a workers. properties file under the conf directory of apache, so that it can be used as an apache plug-in.
Define the workers list structure:
Worker. list = <应用“,”分割的worker 名字列表>
For example:
Worker. list = worker1, worker2
When apache is started, workers. properties is used as a plug-in to initialize and present workers in the worker. list.
2. define the Workers type:
Each named worker should have additional information about it. This information includes the worker type and other related information. The workers type defined in JK1.2.5 is discussed here.
Define the worker type pattern:
Worker. worker name. type =
It is best to follow java naming rules for worker names.
The worker type value is shown in the following table:
Define a worker named "local", which uses the ajpv12 protocol to communicate with Tomcat:
Worker. local. type = ajp12
Define a worker named "remote". its application ajpv13 protocol communicates with Tomcat process:
Worker. remote. type = ajp13
Define a worker named "fast" and use the JNI method to communicate with the Tomcat process:
Worker. fast. type = jni
Define a worker named "loadbalancer", which serves as a load balancing application for multiple Tomcat processes:
Worker. loadbalancer. type = lb
Each type has different actions, which will be described below.
3. set Worker attributes:
After defining a worker, you also need to provide the attributes of each worker. the following methods are used to define these attributes:
Worker .. <属性> = <属性值>
3-1 ajp12 type Worker attribute :.
When ajp12 type worker is working, the ajpv12 protocol based on TCP/IP socket is forwarded to the Tomcat worker "out-of-process.
The attributes of ajp12 worker are as follows:
Host:
Listen to the Tomcat worker host requested by ajp12.
Port:
The listening port of the Tomcat worker host.
Lbfactor:
This attribute is applied when Tomcat worker is used for a server load balancer worker application. It defines the load balancing weight of this worker.
For example, the "worker1" below defines a Tomcat located on the host www.x.com. it listens to the request from apache on port 8007 and has a load weight of 2.5.
Worker. worker1.host = www. x. comworker. worker1.port = 8007worker. worker1.lbfactor = 2.5
Note: In the ajpv12 protocol, a connection must be established, applied, and closed for each request. The default listening port is 8007.
3-2 ajp13 type Worker attributes:
When ajp13 type worker is working, the ajpv13 protocol based on TCP/IP socket is forwarded to the Tomcat worker "out-of-process.
The ajpv13 protocol is significantly different from the ajpv12 protocol:
* Ajpv13 has a richer binary protocol. it uses the frequently used string encoding method to compress the request data.
* Ajpv13 reuses opened sockets and retains these opened sockets to handle future requests. This is necessary in a network environment with a firewall between apache and Tomcat.
* Ajpv13 can process SSL information, so that containers can implement SSL-related methods (such as isSecure ()).
Note: ajp13 can only be used to support Tomcat 4.0.x, 4.1.x and 5 that support the "out-of-process" protocol.
The following table describes the attributes of ajp13worker:
Host:
Listen to the Tomcat worker host requested by ajp13.
Port:
The listening port of the Tomcat worker host.
Lbfactor:
This attribute is applied when Tomcat worker is used for a server load balancer worker application. It defines the load balancing weight of this worker.
Cachesize:
This attribute is valid when JK is applied to a multi-threaded web server (such as apache2.0, IIS, and Netscape. If you set the cachesize value to a higher value, these web servers supporting multithreading will be well processed. If this attribute is not set, the connected cache feature is invalid.
Cache_timeout:
This attribute is used to declare the time when JK retains an open socket in the cache, which helps reduce the number of web serer threads.
Why cache_timeout is applied:
Weekly, a overwhelmed web server (such as apache) builds childs/threads to handle loads, and when the load is reduced, it will burn useless childs/threads. Each child opens an ajp13 connection when forwarding requests to Tomcat, and a ajp13 thread will be established at the Tomcat end to communicate with it. However, the title is displayed after an ajp13 connection is established, child does not promptly release the ajp13 connection, because web server1 will keep its childs/threads running to handle high loads, even if childs/threads processes fast static content, many useless ajp13 threads will be accumulated on Tomcat.
Socket_keepalive:
When the firewall is located between the web server and Tomcat, the firewall will try to disconnect the inactive network connection. This attribute tells the control system to send KEEP_ALIVE information in an inactive connection (the sending interval is dependent on the control system setting, generally 120 seconds ), this will prevent the firewall from discontinuing the inactive network connection.
However, this setting is not a panacea, and it is powerless for some firewalls.
Socket_timeout:
This attribute specifies how long the connection lasts in the inactive state, and the web server will actively disconnect it. This is a good way to avoid too many old Tomcat threads, but it also brings about the overhead to re-open the socket when the next request arrives. This attribute is similar to cache_timeout, but it works in non-cache mode.
Connect_timeout:
After the connection is established, the web server sends a PING request to the connection of the ajp13 protocol. This attribute clarifies the time when the web server waits for a PONG response (in ms ). This attribute was added in jk 1.2.6 to prevent the death of Tomcat, Tomcat 3.3.2, 4.1.28 and 5.0.13 to support ping/pong of application ajp13. This attribute is invalid by default.
Prepost_timeout:
After forwarding a request, the web server sends a PING request to the connection of the ajp13 protocol. This attribute clarifies the time when the web server waits for a PONG response (in ms ). This attribute was added in jk 1.2.6 to prevent the death of Tomcat, Tomcat 3.3.2, 4.1.28 and 5.0.13 to support ping/pong of application ajp13. This attribute is invalid by default.
Reply_timeout:
This attribute tells the web server to wait for a while before receiving the response from another Tomcat in the cluster after the remote Tomcat has died and switches to another Tomcat in real time. By default, the web server will always wait. The attribute value is the time (in ms) for the web server to wait for a response. therefore, be cautious when setting the value for a servlet with a long running time. This attribute was added in jk 1.2.6 to prevent the death of Tomcat and the title generated on the servlet engine supporting ajp13. This attribute is invalid by default.
Recovery_options:
This attribute clarifies how the web server recovers after detecting Tomcat failure. By default, the web server will forward requests to another Tomcat in load balancing mode. The attribute value is 0, indicating that all data is restored; the attribute value is 1, indicating that if Tomcat fails to be restored after receiving the request, the data is not restored; the attribute value is 2, clarify that if Tomcat fails to send an http header to the client, it will not be restored. the attribute value is 3, clarify that if Tomcat fails after receiving the request or fails after Tomcat sends the http header to the client, it will not be restored. This attribute was added in jk 1.2.6 to prevent the death of Tomcat and the title generated on the servlet engine supporting ajp13. This attribute is restored by default.
For example, a worker configuration named "worker2:
Worker. worker2.host
= Www2.x. comworker. worker2.port =
8009worker. worker2.lbfactor
= 3.5worker.worker2.cachesize
= 10worker. worker2.cache _ timeout
= 600worker. worker2.socket _ keepalive
= 1 worker 'worker2' want ajp13 connection to be dropped after
5mn (timeout) worker. worker2.socket _ timeout = 300
Clarification: in the previous example, the worker request control system sends a KEEP-ALIVE signal over the connection.
Note: in ajpv13, the default port is 8009.
4. set lb Worker attributes:
A server load balancer worker does not communicate with Tomcat worker. it manages Tomcat worker.
Its governance scope is as follows:
* Initialize the worker defined in the worker list of the web server.
* Apply the server load balancer weight of worker to perform load balancing based on the weight, and send a large number of requests to the server load balancer with a high weight (in the view of web server, it is more tough) worker.
* Protect the request of the same session on the same Tomcat worker and send it to the same Tomcat worker. To achieve session consistency and continuity on Tomcat worker.
* Identifies failed Tomcat workers, and requests are sent to them. find the workers that can be recovered from failure on other workers managed by lb worker.
Load balancing between multiple workers is managed by the same lb worker (based on their lbfactor and current user session ), you can also try to avoid the adverse effect of the website being "killed" due to the death of a single Tomcat process.
The following table illustrates the properties received by lb worker:
* Balanced_workers: a list of workers separated by ",". it is used to declare the workers to be managed by lb worker. These workers should not be displayed in the worker. list attribute.
* Sticky_session: indicates whether to route the request for session id back to the same Tomcat worker. If the attribute value is not 0, it will be set to JK_TRUE, and the session will be sticky, that is, the request route of the session id will return to the same Tomcat worker; when Tomcat is applying a session Manager that can persist Session data across multiple Tomcat instances, it is set to JK_FALSE. The default attribute value is JK_TRUE.
For example, worker balance1 manages two workers: worker1 and worker2:
Worker. balance1.balanced _ workers = worker1, worker2
5. advanced lb Worker attributes:
JK 1.2.x adds two new attributes: local_worker_only and local_worker, which provide new load balancing and fault tolerance support for lb worker.
Let's take an actual environment as example:
A cluster has two nodes (worker1 worker2), one web server before and after tomcat workers, and one load balancer (lb Worker) located at the front of the node and behind the web server.
The configuration is as follows:
Worker. list = router # Define a 'local _ worker'
Worker using ajp13worker. worker1.port = 8009worker. worker1.host
= Node1.domain. orgworker. worker1.type = ajp13worker. worker1.lbfactor
= 1worker. worker1.local _ worker = 1 # Define another 'local _ worker'
Worker using ajp13worker. worker2.port = 8009worker. worker2.host
= Node2.domain. orgworker. worker2.type = ajp13worker. worker2.lbfactor
= 1worker. worker2.local _ worker = 0 # Define the LB
Workerworker. router. type = lbworker. router. balanced_workers
= Worker1, worker2worker. router. local_worker_only = 1
The local_worker mark on worker1 and worker2 tells lb_worker which connection belongs to the local worker.
If the local_worker value is not 0, it is set to JK_TRUE to mark "local worker", while JK_FALSE is the opposite. If at least one worker is marked as a local worker, lb_worker will work in the local worker mode. In this mode, all local workers will be moved to the header of the internal worker list in lb_worker.
This means that when a request with session id reaches lb_worker, the corresponding worker (the worker with the largest weight according to the weight sorting) will be determined as the receiving/processing person of this request. If this worker dies/becomes a machine, the request will be sent to the first local worker in a non-error state; if a request without session id reaches lb_worker, this request will be routed to the first local worker. If all local workers are in the error state, the "local_worker_only" Mark is particularly important. If the attribute value of local_worker_only is not 0, it is set to JK_TRUE; otherwise, it is set to JK_FALSE. When it is set to JK_TRUE, this request without session id will receive an error as a response; otherwise, lb_worker will try to route the request to another managed worker. If one of the workers is in the error state and the resume of the session is not changed, the local worker will look for the request without the session id (because the session with this pleading is kept in the local worker), while other worker can only look for the request with the session id.
Note: The default value of local_worker is 0, and that of local_worker_only is also 0.
6. why do we need such a complicated process?
Because we need a spiritual protection for a closed node.
The balancer in front of the node periodically queries the specific ports of each node. If we move a node from the cluster, we will implicitly close this specific port. Because the load balancer cannot connect to it, this node will be marked as down. However, we did not move the session on that closed node to another node. In this environment, if the balancer sends a request without session id to a node with a port closed, an error will be generated. If the balancer tests that a node is marked as down, and no other node promises to send a request without a session id. In this way, these old session requests can only be received by routing to the closed node. After a period of time, these old sessions will time out. Because all the old sessions expire, the inaccessible (closed) node will lose the request. At the same time, our servlet system will send a redirection response without session id to the browser.
However, the closed node may be up and participate in the cluster again, and the old session will remain on it. Therefore, after the last session times out, the update node can look forward to the restoration of the old session, rather than killing sessions or moving them to other nodes. And sometimes, if there are many big objects in those old sessions, moving them will take a lot of time.
7. jni type Worker attributes:
Jni worker opens a JVM during the web server process and implements Tomcat in it. this is called "in-process" worker. Messages sent to and from the JVM will be transmitted by calling the JNI method, which makes the jni worker perform faster than the "out-of-process" worker that requires ajp message communication.
Note: jni worker should be used only on the web server (AOLServer, IIS, Netscape and Apache 2.0) that supports the thread because the JVM is multi-threaded. Check whether the thread plan applied on the web server matches the applied JK web server plug-in.
Since jni worker opens a JVM, it will receive some attributes (such as classpath) and pass them to JVM:
Worker. worker name. class_path: classpath to be applied by the JVM in the process. It will contain all Tomcat jar files, class files, configuration files, and so on.
To get support from the JSP compiler, we need to add Javac to classpath. Of course, for java2 tools.jarto classpath, and for jdk1.xx, you must Upload classes.zip to classpath.
Worker. worker name. class_path: used to declare multiple classpath in the form of multiple rows. In the JK environment, use ":" or ";" to connect these classpath.
For example, set classpath for a worker named "wrkjni.
Worker. wrkjni. class_path =/var/tomcat3/lib/tomcat. jarworker. wrkjni. class_path =/opt/IBMJava2-131/lib/tools. jar
Worker. worker name. bridge: identifies the Tomcat type to be applied through the JNI method. This attribute currently has two property values: tomcat32 or tomcat33. Although Tomcat 3.2.x has expired, it is provided for announcement on iSeries-like systems. The default value of this attribute is tomcat33.
For example, set the bridge type to Tomcat 3.3.
Worker. wrkjni. bridge = tomcat33
Worker. worker name. worker _line: this attribute provides the command line for starting code execution in Tomcat. The command and parameter of the command line are divided into multiple performance_line attributes during the application. In the JK environment, the cmd_line is connected by adding spaces between the values of each cmd_line attribute.
For example, set the cmd_line attribute of "wrkjni.
Worker. wrkjni. worker _line =-configworker. wrkjni. worker _line =/etc/tomcat3/conf/alt-server.xmlworker.wrkjni.cmd_line =-homeworker. wrkjni. worker _line =/var/tomcat3
In the example above, The-config parameter name is declared in the first line, and the second line declares the corresponding parameter value. The third line is the same as the fourth line.
Worker. worker name. jvm_lib: used to declare the full path of the JVM implementation Library. The Jni worker application dynamically loads JVM in this path.
For example, set "wrkjni" JVM shared lib (ibm sdk on Linux ).
Worker. wrkjni. jvm_lib =/opt/IBMJava2-131/jre/bin/classic/libjvm. so
For example, set "wrkjni" JVM shared lib (Sun SDK on Windows ).
Worker. wrkjni. jvm_lib = c: \ JDK \ 1.3.1 \ jre \ bin \ classic
Worker. worker name. stdout: sets the full path position of the System. out written by JVM.
For example, set the JVM pre-input path of "wrkjni" to/var/log/http/jk-jvm-out.log.
Worker. wrkjni. stdout =/var/log/http/jk-jvm-out.log
Worker. worker name. stderr: set the full path status of System. err written by JVM.
For example, set the JVM system error pre-input path of "wrkjni" to/var/log/http/jk-jvm-err.log
Worker. wrkjni. stderr =/var/log/http/jk-jvm-out.log
Worker. worker name. ms: set the initial JVM heap size.
For example, set the initial JVM heap of "wrkjni" to 64 MB.
Worker. wrkjni. ms = 64
Worker. worker name. mx: sets the maximum JVM heap size.
For example, the maximum JVM heap size of "wrkjni" is 128 MB.
Worker. wrkjni. mx = 128
Worker. worker name. sysprops: sets the JVM system attributes.
For example, set "wrkjni" to JVM to use French.
Worker. wrkjni. sysprops =-Duser. region = FR
Worker. worker name. ld_path: set the path of the attached dynamic link library (similar to LD_LIBRARY_PATH)
For example, add some dynamic link library paths to the java environment of "wrkjni.
Worker. wrkjni. ld_path =/opt/IBMJava2-131/jre/bin/worker. wrkjni. ld_path
=/Opt/IBMJava2-131/jre/bin/classic
Note: In Linux, the ld_path above cannot update LD_LIBRARY_PATH. Therefore, you must manually update LD_LIBRARY_PATH before performing the web server ,.
8. property file macro:
You can define a macro in the property file ". These macros let us define attributes and apply them later to build other property files. This is useful when we modify the separators of Java Home, Tomcat Home, and system path.
For example, the attributes workers. atat_home and workers. java_home are defined.
Workers. tomcat_home = d: \ tomcatworkers. java_home = d: \ sdk \ jdk1.2.2
When defining worker. inprocess. class_path, you can apply the previously defined workers. tomcat_home.
Worker. inprocess. class_path = $ (workers. tomcat_home) $ (ps) classes
9. a simple and complete worker. properties:
The file defines a relatively complete structure, which can be used as a reference template:
* An ajp12 worker of application port 8007 located in localhost;
* An ajp13 worker of application port 8008 located in localhost;
* One jni worker;
* One lb worker is responsible for load balancing between ajp12 worker and ajp13 workers.
The file content is as follows:
# Define some propertiesworkers. apache_log =/var/log/httpd/workers. tomcat_home
=/Var/tomcat3workers. java_home =/opt/IBMJava2-131/ps
= // # Define 4 workers, 3 real workers using ajp12, ajp13, jni,
The last one being a loadbalancing workerworker. list
= Worker1, worker2, worker3, worker4 # Set properties for worker1 (ajp12)
Worker. worker1.type = ajp12worker. worker1.host
= Locahostworker. worker1.port = 8007worker. worker1.lbfactor
= 5 # Set properties for worker2 (ajp13) worker. worker2.type
= Ajp13worker. worker2.host
= Locahostworker. worker2.port = 8009worker. worker2.lbfactor
= 50worker. worker2.cachesize = 10worker. worker2.cache _ timeout
= 600worker. worker2.socket _ keepalive = 1worker. worker2.socket _ timeout
= 300 # Set properties for worker3 (jni) worker. worker3.type
= Jni # Set worker3 bridge type, here Tomcat 3.3worker.worker3.bridge
= Tomcat33 # Set worker3 classpathworker. worker3.class _ path
= $ (Workers. tomcat_home) $ (ps) classesworker. worker3.class _ path
= $ (Workers. tomcat_home) $ (ps) lib $ (ps) tomcat. jar #
Set worker3 tomcat command lineworker. worker3.cmd _ line
=-Homeworker. worker3.cmd _ line
= $ (Workers. tomcat_home) # Set worker3 Tomcat/JVM
Settingsworker. worker3.jvm _ lib = $ (workers. java_home) $ (ps)
Jre $ (ps) bin $ (ps) classic $ (ps) libjvm. soworker. worker3.stdout
= $ (Workers. apache_log) $ (ps) inprocess. stdoutworker. worker3.stderr
= $ (Workers. apache_log) $ (ps) inprocess. stderrworker. worker3.sysprops
= Tomcat. home = $ (workers. tomcat_home) # Set properties for worker4 (lb)
Which use worker1 and worker2worker. worker4.balanced _ workers = worker1, worker2