SafeChildren Banner

Havoc Oracle Solaris Experts

martes, 31 de agosto de 2010

Instalar ActiveMQ 5 en Solaris 10 - Parte 2

Introducción
En la primera parte de Instalar ActiveMQ en Solaris, vimos como realizar una instalación por defecto sin mayores complicaciones, sin embargo, en esta ocasión veremos como podemos configurar nuestro ActiveMQ para iniciarlo utilizando un sistema de configuración personalizada.

Además, haremos un pequeño repaso a las opciones más importantes y hablaremos de algunos temas de funcionamiento de JMS, como por ejemplo persistencia.

Configuración ActiveMQ
La configuración de ActiveMQ se puede realizar de varias formas, aunque la más customizable es la que utiliza un archivo xml para ello. El formato de ejecución de ActiveMQ es el siguiente:
$ACTIVEMQ_HOME/bin/activemq {opciones} {config_file}
Si no asignamos ningún valor a config_file ActiveMQ utilizará la configuración por defecto -como hemos utilizado en la primera parte- donde nos crean diferentes transportes y activa la consola de administración

Los TransportConnector
Un transportConnector es la definición del servicio donde queremos que nuestro ActiveMQ escuche, es decir, las uri en los cuales hará binding. Su formato es el siguiente:
<transportconnector name="_nombre_" uri="_protocolo_://_hostname_:_port_" />
Existen diferentes tipos de transportConnector, aunque hoy sólo vamos a hablar de dos tipos TCP y NIO podéis encontrar toda la información en Apache ActiveMQ Transport Connectors.

Nos hemos centrado en estos dos tipos, puesto que son sencillos y nos permiten ver la forma de configuración y algún tipo de optimización al utilizar NIO -recordar que hablábamos de Java NIO en Cómo activar Java NIO en Tomcat 6-

La diferencia principal entre tcp y nio reside en que el formato tcp es bloqueante single thread y que nio es no bloqueante multi threard. Cuando hablamos de bloqueante y no bloqueante hacemos referencia a las peticiones -y a su proceso de dispatcher- que en el caso de utilizar tcp procesará cada petición una detrás de la otra.

Esto supone una penalización cuando utilizamos aplicativos web ya que si una petición se cuelga las demás esperarán hasta que se produzca un TimeOut -o se cancele-, para evitar esto utilizaremos el formato nio que, si una petición -mensaje- se cuelga el dispatcher continuará ejecutando las demás.

Todo esto es una forma resumida de explicar el funcionamiento de ActiveMQ, aunque debemos saber que también depende de si tenemos persistencia o no en nuestro sistema de mensajes. Tienes más información sobre persistencia en la página oficial de ActiveMQ Persistence

Qué es eso de Persistencia
En el universo JMS existen opciones para tratar a los mensajes de forma transaccional -al igual que en una base de datos- y por lo tanto, estos mensajes han de ser salvados a disco de forma atómica. Esto supone que si un mensaje JMS con la opción de persistencia activa se almacenará en un lugar hasta que el cliente -o clientes- han devuelto un ack informándo que lo han procesado correctamente.

Además, esto nos permite que ante una caída de nuestro servidor JMS, los mensajes que no se habían enviado, se vuelvan a enviar a aquellos clientes que no los han obtenido.

Toda esta lógica de control es configurable a nivel de cliente pero en el servidor debemos dotar de los mecanismos para que el cliente los pueda utilizar, me explico. Si nosotros no facilitamos soporte de persistencia, aunque nuestro cliente lo configure no funcionará.

Hay que diferenciar la persistencia de la operatividad del servidor, es decir, mientras esté activo utilizará memoria RAM para procesar y almacenar los mensajes, pero si se cae no sabrá dónde estaba y por lo tanto no volverá a reenviar los mensajes pendientes a menos que tengamos el soporte de persistencia activo

Rendimiento vs Tolerancia a Fallos
Debemos tener en cuenta que a mayor tolerancia, menor rendimiento esto es debido a que al aumentar la tolerancia, estamos habilitando un sistema de persistencia en base de datos, o replicación, y por lo tanto, cada mensaje debe pasar por más etapas para completarlo. En la web de Apache ActiveMQ puedes encontrar diferentes configuraciones y explicaciones sobre estas opciones.

Configuración de Nuestro ActiveMQ
Después de un poco de introducción, veámos como podemos configurar nuestro Apache ActiveMQ para tener una configuración personalizada. Para ello, he recreado los archivo de Solaris SMF Manifest ActiveMQ y Solaris SMF Method ActiveMQ ya que he incluido soporte para cargar un archivo de configuración personalizado.

Recordar que deberemos eliminar y volver a importar el archivo de definición (manifest) para que sea efectivo. Además revisar la configuración de nuestro ACTIVEMQ_HOME para que haga referencia a nuestra ubicación.

El contenido de nuestro archivo de ejemplo de configuración de ActiveMQ es la siguiente:
        <transportConnectors>
            <transportConnector name="open" uri="tcp://0.0.0.0:61616"/>
            <transportConnector name="master" uri="nio://0.0.0.0:61816"/>
            <transportConnector name="slave" uri="nio://0.0.0.0:61916"/>
        </transportConnectors>
        <import resource="activemq-admin-console.xml"/>
Y para activar sólo la consola de administración de Apache ActiveMQ incluiremos el resource en nuestro archivo de configuración.

Con todo esto, ya podemos hacer  empezar con nuestras configuraciones, y hacer las diferentes pruebas para ver cuales nos proporcionan el mejor rendimiento.

Conclusiones
Siguiendo con el post anterior, hemos visto como Apache ActiveMQ nos proporciona numerosas opciones de configuración, y que unido a Solaris SMF podemos tener un servidor estable y potente.

En la siguiente parte, hablaremos de Cómo configurar un Transport SSL y las diferentes formas de conexión en modo FailOver para aumentar la disponibilidad de nuestro servicio.



<< Instalación de Apache ActiveMQ - Parte 1


Referencias

No hay comentarios:

Publicar un comentario