Trabajo con hebras

Los nodos de proceso de mensajes y los analizadores deben trabajar en un entorno de varias instancias y varias hebras. Pueden haber muchos objetos de nodo o muchos objetos de analizador y cada uno de los cuales puede tener muchos elementos de sintaxis, y pueden haber muchas hebras que ejecuten métodos en estos objetos. El diseño del intermediario de mensajes asegura que un objeto de mensaje y cualquier objeto que posea lo utilice solamente la hebra que recibe y procesa el mensaje a través del flujo de mensajes.

Una instancia de un nodo de proceso de flujo de mensajes la comparten y la utilizan todas las hebras que dan servicio al flujo de mensajes en el que se ha definido el nodo. En el caso de los analizadores, sólo una hebra individual del flujo de mensajes utiliza una instancia de analizador.

Una extensión definida por el usuario debe seguir este modelo y debe evitar el uso de datos o de recursos globales que requieran semáforos para serializar el acceso entre las hebras. Dicha serialización puede dar como resultados cuellos de botella de rendimiento.

Las funciones de implementación de extensiones definidas por el usuario deben ser reentrantes y cualquier función que invoquen también debe serlo. Todas las funciones del programa de utilidad de extensiones definidas por el usuario son totalmente reentrantes.

Aunque una extensión definida por el usuario puede abarcar hebras adicionales, si es necesario, resulta esencial que la misma hebra devuelva el control al intermediario al finalizar la función de implementación. De no hacerlo se compromete la integridad del intermediario y los resultados pueden ser imprevisibles.

Modelo de ejecución

Cuando se inicializa un grupo de ejecución, se ponen a disposición del tiempo de ejecución los LIL adecuados. El proceso de tiempo de ejecución del grupo de ejecución se inicia y abarca una hebra de configuración dedicada. En el entorno de ejecución del flujo de mensajes, el flujo de mensajes tiene enhebramiento seguro. Puede ejecutar de forma simultánea flujos de mensajes en muchas hebras del sistema operativo sin tener en cuenta cuestiones de serialización. Cualquier nodo definido por el usuario que implemente no debe comprometer este modelo de trabajo con hebras. Tenga en cuenta los puntos siguientes:
  • Un mensaje de entrada enviado a un flujo de mensajes solo lo procesa la hebra que lo recibe. Durante el proceso del mensaje no se produce ninguna conmutación de hebras o de contexto.
  • Las estructuras de datos a las que acceden los flujos de mensajes solamente puede verlas una hebra y estas estructuras de datos solamente existen durante la vida del mensaje que se está procesando.
  • Se comparte una sola instancia de un flujo de mensajes entre todas las hebras de la agrupación de hebras del flujo de mensajes. Esto está relacionado con el comportamiento de un nodo de flujo de mensajes en el sentido que no tiene un estado.
  • Los requisitos de memoria de un grupo de ejecución no resultan afectados indebidamente por los flujos de mensajes que se ejecutan en más hebras del sistema operativo.

Modelo de trabajo con hebras

El siguiente ejemplo de flujo de mensajes le ayudará a comprender algunas de las consideraciones de trabajo con hebras que debe tener en cuenta cuando diseñe e implemente sus propios nodos definidos por el usuario. Tiene en cuenta el ejemplo de un nodo de entrada definido por el usuario.

Se puede configurar un flujo de mensajes para que se ejecute en un conjunto de hebras. Esto lo determina el número de nodos de entrada del flujo de mensajes y el valor de la propiedad additionalInstances del flujo de mensajes. Estos dos elementos determinan la capacidad máxima que la agrupación de hebras del flujo de mensajes puede utilizar. Por lo tanto, si el flujo de mensajes tiene requisitos de proceso determinados que dictan que la ejecución debe ser de una sola hebra, debe asegurarse de que así sea.

Un orden típico de sucesos para un proceso de nodo de entrada sería similar al siguiente:
  1. Se lleva a cabo la creación del nodo de entrada
  2. Se solicita una hebra de la agrupación de hebras
  3. La hebra asignada se inicia en el método run del nodo
  4. Se confirma la configuración (o reconfiguración)
  5. Se lleva a cabo el proceso de inicialización en el contexto de la hebra
  6. La hebra se conecta al gestor de colas del intermediario
  7. Se crean un grupo de mensajes y un objeto de almacenamiento intermedio
  8. Se envía al gestor de colas una petición queue open para la cola de entrada. Esta cola se mantiene abierta mientras dura el ciclo de vida de la hebra.
  9. El nodo de entrada entra en un bucle de proceso de mensaje
  10. Cuando se recibe un mensaje, el almacenamiento intermedio de datos contiene la cabecera y el texto del mensaje
  11. Se crean los objetos de mensaje y se asocian al grupo de la hebra
  12. Se activa el despacho de hebras si se especifican varias hebras
  13. Los datos del mensaje se propagan en sentido descendente.
Debe tener en cuenta lo siguiente:
  • El nodo de entrada implementará el modelo de trabajo con hebras del flujo de mensajes.
  • El nodo de entrada siempre tendrá al menos una hebra que o bien lee su origen de entrada o bien procesa activamente un mensaje recibido. Si un flujo de mensajes tiene varios nodos de entrada, entonces cualquier instancia de hebra adicional estará disponible para dar servicio a cualquiera de los nodos de entrada, según lo determine la política de despacho de dicho nodo de entrada.
Se puede solicitar las hebras. Cuando se despliega el flujo de mensajes, el nodo de entrada solicita una hebra inicial. Aunque el flujo de mensajes tiene asociada una agrupación de hebras, es el nodo de entrada el responsable de la política para el despacho de las mismas. Esto significa que siempre necesita asegurarse de que hay una instancia propia ejecutándose en una hebra. Debido a que el valor por omisión de la propiedad additionalInstances es cero, cualquier petición adicional de una hebra fallará si ha definido varios nodos de entrada. Esto significa que un flujo de mensajes puede consumir más hebras de las que tiene previsto. Asimismo, esto puede significar que si ha definido varios nodos de entrada, uno de los nodos de entrada puede estar necesitando hebras.

La forma más eficaz de impedir que la cola de entrada se convierta en un cuello de botella es permitir que el intermediario inicie copias adicionales de la propiedad additionalInstances. No obstante, crear hebras diferentes permite un proceso paralelo de los mensajes de la cola de mensajes, por lo tanto, sólo se utiliza esta propiedad cuando el orden en que se procesan los mensajes no es importante.

Las hebras se crean como resultado de la creación y operación de nodos de entrada. Una hebra permanece activa o desocupada en la agrupación de hebras, las hebras desocupadas permanecen en la agrupación hasta que las despacha un nodo de entrada o hasta que concluye el intermediario.

La figura siguiente muestra la asignación de hebras en un flujo de mensajes.

Asignación de hebras en un flujo de mensajes


Consulte el texto que le acompaña para obtener una descripción de los elementos del diagrama

Inicialmente, se solicita la hebra 1 (A) y ésta espera los mensajes. Cuando llega un mensaje (B), la hebra 1 propaga el mensaje y despacha la hebra 2. La hebra 2 recibe un mensaje inmediatamente (C) y propaga y despacha la hebra 3, la cual espera un mensaje (D). La hebra 1 se completa (E) y regresa a la agrupación de hebras. La hebra 3 recibe a continuación un mensaje (F), despacha la hebra 1 y propaga el mensaje. Ahora la hebra 1 espera a que llegue el mensaje en la cola (G).

Vale la pena tener en cuenta el punto marcado con una H. En este punto del flujo de mensajes, la hebra 1 adquiere un mensaje pero debido a que todas las demás hebras están activas en ese momento, no se puede despachar. El mensaje se propaga.

Después de que se ha propagado este mensaje, la hebra 2 se completa (I), recibe un mensaje nuevo de la cola y propaga este mensaje nuevo. A continuación, la hebra 3 se completa (J) y regresa a la agrupación. A continuación, la hebra 2 se completa (K). Debido a que no se ha despachado, cuando se completa la hebra 1 (L) no puede regresar a la agrupación de hebras incluso cuando no hay mensajes en la cola y, en su lugar, espera a que llegue un mensaje en la cola.

Tenga en cuenta los puntos siguientes en relación con el comportamiento de las hebras en WebSphere Message Broker:
  • Las hebras solo se crean si lo requiere la carga de trabajo. Esto significa que un proceso de grupo de ejecución puede utilizar menos hebras de las que tiene configuradas.
  • A menos que todas las hebras disponibles estén procesándose activamente en un flujo de mensajes, una hebra siempre estará leyendo la cola de entrada.
  • Si la carga de trabajo aumenta llegado este punto, otros nodos de entrada del mismo flujo de mensajes podrán adquirir hebras que se han devuelto a la agrupación de hebras.
Si un hebra adquiere un mensaje pero todas las demás hebras están activas en ese momento, no podrá despacharlo. El mensaje se propagará. Cuando se complete la hebra, debido a que la hebra no ha podido despachar, no podrá regresar a la agrupación a pesar de que no hay mensajes en la cola.
Referencia relacionada
cniDispatchThread
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
as01460_