WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Gestión de conexiones

Las conexiones TCP/IP las solicita el gestor de conexiones de cliente y las acepta el gestor de conexiones de servidor.

El proceso del grupo de ejecución contiene el gestor de conexiones, que establece las conexiones. Únicamente un grupo de ejecución puede tener nodos de servidor que utilicen un puerto específico en un momento determinado; el despliegue a un segundo grupo de ejecución causaría un error de despliegue. Se pueden desplegar nodos de cliente en distintos grupos de ejecución, pero cada grupo de ejecución tiene su propia agrupación de conexiones y, por tanto, su propio número máximo y mínimo de conexiones.

Los nodos TCPIP no crean ni gestionan directamente ninguna conexión TCP/IP, sino que las adquieren de la agrupación interna del gestor de conexiones. Por ejemplo, dos nodos de salida que utilicen los mismos detalles de conexión comparten el mismo gestor de conexiones. Los nodos TCPIP pueden definir los detalles de conexión que van a utilizarse, especificando uno de los siguientes valores:

Si se han especificado un nombre de host y un puerto, el nodo utilizará esos valores cuando solicite conexiones. Si se especifica un servicio configurable, el nodo obtiene los valores para el nombre de host y el puerto en los valores definidos en el servicio configurable. El gestor de conexiones da soporte a otros parámetros configurables además del nombre de host y el puerto, y se pueden definir todos estos los valores cuando se utiliza un servicio configurable. Cuando en el nodo se ha especificado el nombre de host y el puerto, el gestor de conexiones obtiene el resto de valores necesarios del servicio configurable predeterminado. Sin embargo, si se ha definido un servicio configurable que utilice el nombre de host y el número de puerto, se utilizarán los valores de ese servicio configurable.

El gestor de conexiones se crea cuando se despliega el primer nodo que requiere conexiones del mismo. El gestor de conexiones se suprime cuando el último nodo restante que lo utiliza se ha eliminado del grupo de ejecución (lo que significa que el gestor de conexiones ya no está siendo utilizado por ningún nodo desplegado). Por ejemplo, este proceso puede ocurrir cuando se vuelven a desplegar flujos existentes, ya que el nuevo despliegue implica la supresión de todos los nodos existentes antes de crearlos de nuevo.

El gestor de conexiones aplica los cambios realizados en un servicio configurable TCPIPClient sin necesidad de reiniciar los grupos de ejecución. El gestor de conexiones aplica los cambios del servicio configurable TCPIP a todos los flujos de mensajes que utilicen dicho servicio. Aplicar cambios del servicio configurable TCPIP implica reiniciar los gestores de conexiones TCPIP, de forma que se puede esperar que todos los flujos que utilizan servicios configurables para especificar parámetros TCPIP recojan nuevas conexiones TCPIP.

El gestor de conexiones actualiza los nodos afectados sólo después de que cada flujo de mensajes afectado haya procesado el mensaje actual. Cuando un flujo de mensajes afectado haya procesado el mensaje actual, dicho flujo de mensajes se bloqueará, hasta que hayan finalizado las actualizaciones de todos los flujos de mensajes afectados. Este proceso sirve para garantizar que cada nodo que pertenezca al mismo grupo de ejecución utilice el mismo valor para el servicio configurable que se haya modificado. Por esta razón, es posible que haya un retardo de varios segundos entre la aplicación de la actualización al servicio configurable, y las propiedades que utilice el flujo de mensajes que se esté actualizando.

Conexiones de servidor

El gestor de conexiones del servidor empieza a escuchar conexiones de servidor cuando se inicia y sigue aceptando conexiones hasta que se alcanza el número máximo de conexiones (según se especifica en el servicio configurable). Al llegar a este punto, se rechazan todos los intentos de realizar conexiones. Los servidores TCP/IP no crean conexiones; únicamente aceptan solicitudes de conexión de otras aplicaciones. Por tanto, no puede forzar la creación de conexiones dentro de un flujo de mensajes.

Conexiones de cliente

El gestor de conexiones del cliente se inicia y sigue haciendo conexiones de cliente hasta que se alcanza el número mínimo de conexiones (según lo definido en el servicio configurable). De forma predeterminada, el número mínimo es cero, lo que indica que no se han realizado conexiones. Siempre que el número de conexiones queda por debajo del valor mínimo, el gestor de conexiones empieza a crear más conexiones de cliente. Los nodos de cliente de salida y de recepción inician la creación de nuevas conexiones de cliente siempre que no queda ninguna disponible para que ser utilizada, a menos que se haya alcanzado el número máximo (según lo definido en el servicio configurable).

Reserva y liberación de conexiones

Cada conexión tiene una corriente de entrada y una corriente de salida y ambas tienen dos estados principales dentro del gestor de conexiones: disponible y reservada.

Cuando un nodo solicita una conexión para efectuar una entrada o una salida sin especificar el ID de una conexión determinada, se le da cualquier conexión disponible en la corriente de datos requerida. Si no hay ninguna conexión disponible y el nodo es un nodo de cliente, únicamente se crea una nueva conexión si no se ha alcanzado aún el número máximo de conexiones. Cualquier conexión cuyo estado sea disponible puede ser utilizada por un solo nodo a la vez, pero cuando dicho nodo haya terminado de utilizarla cualquier otro nodo (desde cualquier flujo o hebra) podrá acceder a ella.

Se puede restringir el acceso a una corriente de una conexión reservando dicha conexión. Cuando una conexión esté en estado reservad ningún otro nodo podrá acceder a la corriente sin especificar el ID de la conexión. Por ejemplo, un nodo de entrada puede solicitar una conexión disponible y, cuando haya terminado de leer los datos, dejar la corriente en estado reservado. Mientras la corriente de datos está en el estado reservado, ningún nodo de entrada (incluido el nodo que dejó la corriente en estado reservado) puede acceder a ella debido a que los nodos de entraba sólo pueden acceder a corrientes de datos disponibles. A los únicos nodos que pueden acceder a la corriente de datos es necesario que tengan el ID de conexión que se graba en el entorno local de salida cuando los datos pasan adelante por el flujo de mensajes Como consecuencia, los nodos de recepción pueden leer más datos en la misma conexión, pero sólo si el nodo de recepción está configurado para utilizar el ID del entorno local del nodo de entrada.

Cuando una conexión está reservada, se otorga la propiedad de la conexión a una hebra de proceso actual. Si es necesario, este proceso puede distribuir distintos flujos de mensajes.

El mecanismo de reserva proporciona las siguientes opciones:
  • Dejar sin cambios
  • Reservar
  • Liberar
  • Reservar y liberar al final del flujo

Para todos los nodos, la corriente se deja disponible (no reservada) de forma predeterminada. Para muchos tipos de proceso, puede dejar este valor predeterminado sin cambiar; por ejemplo, cuando esté trasladando datos de una corriente de entrada a un archivo. La finalidad principal de reservar una corriente de datos es conectar una serie de nodos para proporcionar un proceso complejo a una corriente de datos en una secuencia ordenada, controlada y síncrona.

Puede utilizar la opción Reservar y liberar al final del flujo para reservar una conexión y para asegurar que la corriente de datos de la conexión se libere cuando una iteración del flujo de mensajes haya terminado de procesarse (incluyendo cualquier condición de error que pueda ocurrir).

Si necesita que el proceso abarque varios flujos de mensajes (por ejemplo, para solicitud y respuesta asíncronas), debe reservar una corriente sin liberarla al final del flujo de mensajes. Consulte el ejemplo siguiente:

Puede ver información sobre los ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit o el Information Center en línea. Puede ejecutar ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit.

Una desventaja de reservar una corriente entre flujos de mensajes es que existe la posibilidad de que una corriente de datos no se llegue a liberar nunca. Para evitar este problema, establezca una hora de caducidad en la conexión de forma que se cierre tras un periodo de inactividad especificado.

Otra ventaja de reservar una corriente de entrada es que la conexión no se puede cerrar hasta que se libera o caduca (incluso si una aplicación final cierra su extremo de la conexión) que es útil cuando se utiliza el extremo de la corriente para delimitar mensajes en la corriente.

Descriptores de archivos

Si su aplicación WebSphere Message Broker se está ejecutando en Sun Solaris 10 en SPARC, puede que tenga que aumentar el número de descriptores de archivos. El siguiente error en el syslog indica que se necesitan descriptores de archivo adicionales:
 Error al crear una conexión de cliente utilizando el nombre de host: '', puerto: ''. Razón: 'Argumento no válido'
También puede probar los dos métodos siguientes para resolver el error:
  • Cambiar la variable de entorno MQSIJVERBOSE, por ejemplo:
    export MQSIJVERBOSE=-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider
  • Cambiar el límite de número máximo de descriptores de archivo a valor, en lugar de RLIM64_INFINITY
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:58


Tema de conceptoTema de concepto | Versión 8.0.0.5 | ac67380_