Zona HTML Zona Java Zona PHP Zona ASP Zona Bases de datos
-Tutoriales

Tomcat - Introducción


Los Workers Tomcat

Un worker Tomcat es un ejemplar Tomcat que está esperando para ejecutar servlets por cuenta de algún servidor web. Por ejemplo, podemos tener un servidor web como Apache reenviando peticiones servlets a un proceso Tomcat (el worker que se ejecuta detrás de él.

El escenario descrito arriba es uno muy simple; de hecho uno puede configurar múltiples workers para servir servlets por cuenta de un cierto servidor web. Las razones para dicha configuración pueden ser:

  • Queremos que diferentes contextos sean servidos por diferentes workers Tomcat para proporcionar un entorno de desarrollo donde todos los desarrolladores compartan el mismo servidor pero con su propio worker Tomcat.
  • Queremos que diferentes host virtuales servidos por diferentes procesos Tomcat proporcionen una clara separación entre los sites pertenecientes a distintas compañías.
  • Queremos proporcionar un balance de carga, lo que significa ejecutar múltiples workers Tomcat cada uno en su propia máquina y distribuir las peticiones entre ellos.

Probablemente haya más razones para tener múltiples workers pero creo que esta lista es suficiente...

Los workers están definidos en un fichero de propiedades llamado workers.properties y está página explica como trabajar con él.

. Definir Workers

La definición de workers para el plugin Tomcat del servidor web puede hacerse usando un fichero de propiedades (un fichero de ejemplo llamado workers.properties está disponible en el directorio conf/); el fichero contiene entradas con la siguiente forma:

worker.list=<una lista separada por comas de nombres de workers >

Por ejemplo:

worker.list= ajp12, ajp13

Y

worker.<nombre de worker>.<property>=<valor de propiedad>

Por ejemplo:

worker.local.port=8007

Cuando arranque, el plugin del servidor web ejemplarizará los workers cuyos nombres aparezcan en la propiedad worker.list, estos también son los workers a los que podemos mapear peticiones.

Cada worker nombrado debería tener una pocas entradas para proporcionar información adicional sobre sí mismo; esta información incluye el tipo de worker y otra información relacionada. Actualmente existen estos tipos de workers en (Tomcat 3.2-dev):

Tipo de Worker Description
ajp12 Este worker sabe cómo reenviar peticiones a workers Tomcat fuera-de-proceso usando el protocolo ajpv12.
ajp13 Este worker sabe cómo reenviar peticiones a workers Tomcat fuera-de-proceso usando el protocolo ajpv13.
jni Este worker sabe cómo reenviar peticiones a workers Tomcat fuera-de-proceso usando jni.
lb Este es un worker de balance de carga, que sabe como proporcionar un balance de carga basado en redondeo con un cierto nivel de tolerancia.

Definir workers de un cierto tipo debería hacerse siguiendo este formato de propiedad:

worker.<worker name>.type=<worker type>

Donde worker name es el nombre asignado al worker y worker type es uno de los cuatro tipos definidos en la tabla. Un nombre de worker podría no contener espacios (una buena convención de nombres sería utilizar las reglas de nombrado para las variables Java).

Por ejemplo:

Definición de Worker Significado
worker.local.type=ajp12 Define un worker llamado "local" que usa el protocolo ajpv12 para reenviar peticiones a un proceso Tomcat.
worker.remote.type=ajp13 Define un worker llamado "remote" que usa el protocolo ajpv13 para reenviar peticiones a un proceso Tomcat.
worker.fast.type=jni Define un worker llamado "fast" que usa JNI para reenviar peticiones a un proceso Tomcat.
worker.loadbalancer.type=lb Define un worker llamado "loadbalancer" que hace balance de carga de varios procesos Tomcat de forma transparente.

. Configurar Propiedades del Worker

Después de definir los workers podemos especificar propiedades para ellos. Las propiedades se pueden especificar de la siguiente manera:

worker.<worker name>.<property>=<property value>

Cada worker tiene un conjunto de propiedades que podemos configurar según se especifica en las siguientes subsecciones:

. Propiedades de un Worker ajp12

Los workers del tipo ajp12 reenvían peticiones a workers Tomcat fuera-de-proceso usando el protocolo ajpv12 sobre sockets TCP/IP. La siguiente tabla especifica las propiedades que puede aceptar un worker ajp12:

Nombre de
Propiedad
Significado Ejemplo
port El puerto donde el worker Tomcat escucha peticiones ajp12. worker.local.port=8007
host El host donde el worker Tomcat escucha peticiones ajp12. worker.local.host=www.x.com
lbfactor Cuando trabaja con un worker de balance de carga, este es el factor de balance para el worker. worker.local.lbfactor=2.5

. Propiedades de un Wroker ajp13

Los workers del tipo ajp13 reenvían peticiones a workers Tomcat fuera-de-proceso usando el protocolo ajpv13 sobre sockets TCP/IP. Las principales diferencias entre ajpv12 y ajpv13 son que:

  1. ajpv13 es un protocolo más binario e intenta comprimir algunos de los datos solicitados codificando los strings más frecuentemente usados en enteros pequeños.
  2. ajpv13 reusa sockets abiertos y los deja abiertos para futuras peticiones.
  3. ajpv13 tiene un tratamiento especial para información SSL por eso el contenedor puede implementar métodos relacionados cono SSL como isSecure().

La siguiente tabla especifica las propiedades que puede aceptar un worker ajp13:

Nombre de
Propiedad
Significado Ejemplo
port El puerto donde el worker Tomcat escucha peticiones ajp12. worker.local13.port=8007
host El host donde el worker Tomcat escucha peticiones ajp12. worker.local13.host=www.x.com
lbfactor Cuando trabaja con un worker de balance de carga, este es el factor de balance para el worker. worker.local13.lbfactor=2.5
cachesize Especifica el número de conexiones sockets abiertas que mantendrá el worker. Por defecto este valor es 1, pero los servidores web multi-thread como Apache2.xx, IIS, y Netscape se beneficiarán si configuramos este valor a un nivel más alto (como una media estimada de los usuarios concurrentes de Tomcat). worker.local13.cachesize=30

. Propiedades de un Worker lb

El worker de balanceo de cargas realmente no se comunica con otros workers Tomcat, en su lugar es el responsable de varios workers "reales". Este control incluye:

  • Ejemplarizar los workers en el servidor web.
  • Usar el factor de balanceo de carga, realizando un balanceo de carga al redondeo de peso donde el lbfactor más alto significa una máquina más fuerte (es la que manejará más peticiones).
  • Seguimiento de las peticiones que pertenecen a la misma sesión y que se ejecutan en el mismo worker Tomcat.
  • Identificar los workers Tomcat fallidos, suspender las peticiones a estos workers y hacer que otros workers las manejen.

El resultado general es que los workers manejados por el mismo worker lb tienen balance de cargas (basándose en su lbfactor y la sesión de usuario actual) y tambíen tienen anti-caída por lo que si un proceso Tomcat muere, no "matará" toda la site.

La siguiente tabla especifica las propiedades que puede aceptar un worker lb:

Nombre de
Propiedad
Significado Ejemplo
balanced_workers Una lista separada por comas de workers que el balanceador de carga necesita manejar. Estos workers no deberían aparecer en la propiedad worker.list. worker.loadbalancer.balanced_workers= local13, local12

. Propiedades de un Worker jni

El worker jni abre una JVM dentro del proceso del servidor web y ejecuta Tomcat dentro de ella (es decir en-proceso). Después de esto, los mensajes pasados hacia y desde la JVM son pasados usando llamadas a métodos JNI, esto hace al worker jni más rápido que los workers fuera-de-proceso que necesitan comunicarse con los workers Tomcat escribiendo mensajes AJP sobre sockets TCP/IP.

Nota: como la JVM es multi-thread; el worker jni sólo se debería usar dentro de servidores multi-thread como AOLServer, IIS, Netscape y Apache2.0. Deberíamos asegurarnos de que el esquema de threads usado por el servidor web corresponde con el usado para construir el plugin jk del servidor web.

Como el worker jni abre una JVM puede aceptar tantas propiedades como pueda reenviar a la JVM como el classpath, etc. como podemos ver en la siguiente tabla:

Nombre de
Propiedad
Significado Ejemplo
class_path El casspath usado por la JVM en-proceso. Esto debería apuntar a todos los ficheros jar/file de Tomcat así como a cualquier clase u otro fichero jar que queramos añadir a la JVM
Deberíamos recordar añadir también javac al classpath. Esto se hace en Java2 añadiendo tools.jar al classpath. En JDK1.xx deberíamos añadir classes.zip.
La propiedad class_path se puede dividir en múltiples líneas. En este caso el entorno jk concatenará todas las entradas classpath poniendo un delimitador (":"/";") entre cada entrada.
worker.localjni.class_path=path-to-some-jarfile
worker.localjni.class_path=path-to-class-directory
cmd_line La línea de comandos que es manejada sobre el código de arranque de Tomcat.
La propiedad cmd_line puede proporcionarse en múltiples líneas. En este caso el entorno jk las concatenará poniéndo espacios entre ellas.
Nota: El string cmd_line no soporta espacios en blanco embebidos. Esto afecta principalmente a las especificaciones de paths. Sobre windows, podemos usar los nombres MS-DOS 8.3 para directorios que de otro modo contendrían un espacio en blanco.
worker.localjni.cmd_line=-config
worker.localjni.cmd_line=path-to-tomcats-server.xml-file
worker.localjni.cmd_line=-home
worker.localjni.cmd_line=-path-to-tomcat-home
jvm_lib El path completo a la librería de implementación de la JVM. El worker jni usa este path para cargar la JVM dinámicamente. worker.localjni.jvm_lib=full-path-to-jvm.dll
stdout El path completo donde la JVM escribirá su System.out worker.localjni.stdout=full-path-to-stdout-file
stderr El path completo donde la JVM escribirá su System.err worker.localjni.stderr=full-path-to-stderr-file
sysprops Propiedades de sistema para la JVM. worker.localjni.sysprops=some-property
ld_path Path a las librerías dinámicas adicionales (similar en naturaleza a LD_LIBRARY_PATH). worker.localjni.ld_path=some-extra-dynamic-library-path

. Macros en Ficheros de Propiedades

Desde Tomcat3.2 podemos definir macros en los ficheros de propiedades. Estas macros nos permite definir propiedades y posteriormente usarlas cuando construyamos otras propiedades. Por ejemplo, el siguiente fragmento:

workers.tomcat_home=c:\jakarta-tomcat
workers.java_home=c:\jdk1.2.2
ps=\
worker.inprocess.class_path=$(workers.tomcat_home)$(ps)classes
worker.inprocess.class_path=$(workers.java_home)$(ps)lib$(ps)tools.jar

Terminará con los siguientes valores para las propiedades worker.inprocess.class_path:

worker.inprocess.class_path= c:\jakarta-tomcat\classes
worker.inprocess.class_path=c:\jdk1.2.2\lib\tools.jar

. El ejemplo worker.properties

Como escribir worker.properties por nosotros mismos no es una cosa fácil de hacer; junto con los paquetes de Tomcat3.2 (y superiores) viene un fichero worker.properties de ejemplo. Este fichero está pensado para ser tan genérico como sea posible y usa extensivamente las macros de propiedades.

El ejemplo worker.properties contiene el siguiente nivel de definiciones:

  1. Un worker ajp12 que usa el host localhost y el puerto 8007.
  2. Un worker ajp13 que usa el host localhost y el puerto 8009.
  3. Un worker jni.
  4. Un worker lb que balancea la carga de los workers ajp12 y ajp13.

Las definicioens de los workers ajp12, ajp13 y lb pueden funcionar sin modificar el fichero. Sin embargo, para hacer que funcione el worker jni deberemos configurar las siguientes configuraciones en el fichero:

  • workers.tomcat_home
    - tiene que apuntar a nuestro tomcat_home.
  • workers.java_home
    - tiene que apuntar a donde tengamos situado el JDK.
  • ps
    - tiene que apuntar al separador de ficheros de nuestro sistema operativo.

Cuando hagamos esto, el worker jni por defecto, debería funcionar.

 
Patrocinados
 

Copyright © 1999-2006 Programación en castellano. Todos los derechos reservados.
Formulario de Contacto - Datos legales - Publicidad

Hospedaje web y servidores dedicados linux por Ferca Network