![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.
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().
- 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:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)

- Cuando se inicia el puerto de escucha, éste obtiene una hebra de la agrupación de hebras del servicio de escucha de mensajes.
- 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.
- El puerto de escucha crea una transacción para gestionar el proceso de mensajes.
- 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().
- 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.
- Si el mensaje es adecuado, el método receive() lo toma del destino y lo envía a la hebra.
- La hebra invoca el método onMessage() del MDB del consumidor de mensaje y se procesa el mensaje.
- 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.
- Se inicia una nueva transacción y consumidor de mensajes invoca al método receive() para que permanezca a la escucha de mensajes nuevos.
- Cuando se inicia el puerto de escucha, éste obtiene dos hebras de la agrupación de hebras del servicio de escucha de mensajes.
- 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.
- Ambos consumidores de mensajes invocan al método receive() para que escuche mensajes en el destino. Los consumidores compiten para obtener mensajes del destino.
- 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.
- 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.
- La hebra llama al método receive() para escuchar mensajes.
- Después de 110 segundos, en el destino aparece un mensaje.
- La hebra elimina el mensaje del destino y llama al método onMessage() del MDB para empezar a procesar el mensaje.
- 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.
- Pasados 5 segundos, el método onMessage() acaba de procesar el mensaje e intenta confirmar la transacción.
- 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.