[AIX Solaris HP-UX Linux Windows][IBM i]

Cómo se procesan los mensajes en modalidad no ASF

En modalidad no ASF las hebras están activas desde el momento en que se inicia el puerto de escucha. El número de hebras activas lo dicta el valor especificado en Número máximo de sesiones. Está activa la cantidad de hebras especificada en Número máximo de sesiones, independientemente de la cantidad de mensajes que estén disponibles para su proceso. Cada hebra activa es una conexión de red física independiente.

Si está utilizando IBM MQ Versión 7.0 o posteriores como proveedor de mensajería, puede tener hasta diez hebras compartiendo una misma conexión de red física.

Para WebSphere Application Server versión 7 y posteriores, los puertos de escucha se estabilizan. Para obtener más información, consulte el artículo sobre las características que se han estabilizado. Debe planificar la migración de sus configuraciones de despliegue de beans controlados por mensajes de WebSphere MQ para pasar de utilizar puertos de escucha a utilizar especificaciones de activación. [AIX Solaris HP-UX Linux Windows][IBM i]Para obtener más información sobre cómo configurar especificaciones de activación para la modalidad no ASF, consulte Configuración de especificaciones de activación para la modalidad no ASF. No obstante, no debe iniciar esta migración hasta que esté seguro de que la aplicación no tiene que trabajar con servidores de aplicaciones anteriores WebSphere Application Server Versión 7. Por ejemplo, si tiene un clúster de servidor de aplicaciones con algunos miembros de la versión 6.1 y otros de una versión posterior, no debe migrar las aplicaciones en dicho clúster para que utilicen las especificaciones de activación hasta que haya migrado todos los servidores de aplicaciones del clúster a la versión posterior.

Proceso de mensajes en modalidad no ASF

Para activar la modalidad no ASF, especifique un valor distinto de cero para la propiedad personalizada del servicio de escucha de mensajes NON.ASF.RECEIVE.TIMEOUT. NON.ASF.RECEIVE.TIMEOUT actúa como un conmutador que desactiva la modalidad ASF y también como un valor de tiempo de espera para el método receive().

Nota: Las propiedades personalizadas del servicio de escucha de mensajes siguientes no funcionan en la modalidad no ASF:
  • SERVER.SESSION.POOL.REAP
  • SERVER.SESSION.POOL.UNUSED.TIMEOUT
  • SERVER.SESSION.POOL.UNUSED.TIMEOUT.Ipaname

El siguiente diagrama muestra cómo tiene lugar el proceso de mensajes entre WebSphere Application Server y IBM MQ en modalidad no ASF:

Figura 1. Proceso de mensajes en modalidad no ASF
[AIX Solaris HP-UX Linux Windows][IBM i]La figura se describe en el texto circundante.
Como se muestra en el diagrama, cuando el servicio de escucha de mensajes funciona en modalidad no ASF, los mensajes se procesan de la siguiente manera:
  1. Cuando se inicia el puerto de escucha, éste obtiene una hebra de la agrupación de hebras del servicio de escucha de mensajes.
  2. El puerto de escucha abre una conexión con el gestor de colas IBM MQ en la hebra y crea un consumidor de mensajes JMS. El consumidor de mensaje permanece a la escucha en el destino JMS cuyo puerto de escucha se ha configurado para la escucha.
  3. El puerto de escucha crea una transacción para gestionar el proceso de mensajes.
  4. La hebra invoca al método receive() en el consumidor de mensajes para escuchar mensajes en el destino. Si el método receive() no detecta un mensaje en el tiempo especificado para NON.ASF.RECEIVE.TIMEOUT, el servidor de aplicaciones retrotrae la transacción activas e inicia una nueva. A continuación, la hebra empieza a invocar de nuevo al método receive().
  5. cuando el consumidor de mensaje detecta un mensaje, lo comprueba para ver si el mensaje es adecuado para el MDB que está utilizando el puerto de escucha.
  6. Si el mensaje es adecuado, el método receive() lo toma del destino y lo envía a la hebra.
  7. La hebra invoca el método onMessage() del MDB del consumidor de mensaje y se procesa el mensaje.
  8. Si el mensaje se termina de procesar satisfactoriamente, se confirma la transacción. Si el mensaje no se procesa correctamente, la transacción se retrotrae.
  9. Se inicia una nueva transacción y consumidor de mensajes invoca al método receive() para que permanezca a la escucha de mensajes nuevos.
El número de hebras que un MDB pueden procesar de forma simultánea viene determinado por el valor de la propiedad Número máximo de sesiones para el puerto de escucha. Si establece Número máximo de sesiones en el valor predeterminado 1, el MDB sólo puede procesar un mensaje cada vez. Si desea procesar más de un mensaje de forma simultánea, puede hacerlo en la modalidad ASF estableciendo Número máximo de sesiones en un valor mayor que 1. Por ejemplo, si establece Número máximo de sesiones en 2, los mensajes se procesan de la siguiente manera:
  1. Cuando se inicia el puerto de escucha, éste obtiene dos hebras de la agrupación de hebras del servicio de escucha de mensajes.
  2. El puerto de escucha crea un consumidor de mensajes y una transacción en cada hebra. Los consumidores de mensajes escuchan el destino en el que se ha configurado el puerto de escucha.
  3. Ambos consumidores de mensajes invocan al método receive() para que escuche mensajes en el destino. Los consumidores compiten para obtener mensajes del destino.
  4. Cuando uno de los consumidores recupera satisfactoriamente el mensaje, lo procesa invocando el método onMessage() del MDB. Los otros consumidores de mensajes continúan llamando al método receive() para escuchar mensajes del destino.

Cómo evitar tiempos de espera de transacción no deseados

Si el sistema de mensajería se está ejecutando en la modalidad no ASF, para evitar tiempos de espera de transacción no deseados, deberá autorizar una cantidad suficiente de tiempo para que se complete el proceso, antes de que se alcance el tiempo de espera de la duración total de la transacción. Por lo tanto, debe asegurarse de que el valor que especifique para la propiedad personalizada del servicio de escucha de mensajes NON.ASF.RECEIVE.TIMEOUT sea menor que el valor que especifique para la propiedad de servicio de transacciones Tiempo de espera de actividad total de transacción y, también, que la diferencia entre los valores de las dos propiedades sea mayor que la cantidad de tiempo que el método onMessage() del bean controlado por mensaje (MDB) tarda en procesar el mensaje.

Tal como se muestra en el ejemplo siguiente, si estas propiedades no se han configurado correctamente, las transacciones pueden agotar el tiempo de espera antes de completarse. Esto se debe a que la hebra empieza a llamar al método receive() tan pronto como se crea la transacción. En el ejemplo siguiente, NON.ASF.RECEIVE.TIMEOUT se establece en 110000 milisegundos (110 segundos), Tiempo de espera de actividad total de transacción se establece en 120 segundos y el método onMessage () del MDB tarda 15 segundos en procesar un mensaje. El ejemplo da por supuestos que no aparece un mensaje en el destino hasta que el método receive() haya casi excedido el tiempo de espera:
  1. Se inicia el puerto de escucha. Se asigna una hebra de la agrupación de hebras y se crea una transacción y un consumidor de mensajes en la hebra.
  2. La hebra llama al método receive() para escuchar mensajes.
  3. Después de 110 segundos, en el destino aparece un mensaje.
  4. La hebra elimina el mensaje del destino y llama al método onMessage() del MDB para empezar a procesar el mensaje.
  5. Pasados 10 segundos, se alcanza el tiempo de espera de la transacción. El servidor de aplicaciones marca la transacción para su retrotracción.
  6. Pasados 5 segundos, el método onMessage() acaba de procesar el mensaje e intenta confirmar la transacción.
  7. La cantidad total de tiempo que ha transcurrido desde que se inició la transacción es 125 segundos (110 segundos esperando un mensaje, más 15 segundos para procesar el mensaje). Puesto que este periodo de tiempo es superior al tiempo de espera de la transacción, el servidor de aplicaciones impide que se confirme la transacción y se retrotrae.

Para obtener más información acerca de cómo configurar las propiedades NON.ASF.RECEIVE.TIMEOUT y Tiempo de espera de actividad total de transacción para evitar que se excedan los tiempos de espera en transacciones, consulte las tareas relacionadas.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmb_asfnonasf_nonasf
File name: cmb_asfnonasf_nonasf.html