java - una - Relación entre conexiones JMS, sesiones y productores/consumidores

crear usuario y contraseña en java netbeans (5)

Deseo enviar un lote de 20k mensajes JMS a la misma cola. Estoy dividiendo la tarea usando 10 hilos, por lo que cada uno procesará 2k mensajes. No necesito transacciones.

Me preguntaba si tener una conexión, una sesión y 10 productores es el camino recomendado o no.

¿Qué tal si tuviera un productor compartido por todos los hilos? ¿Serán mis mensajes corruptos o se enviarán sincronizados (sin obtener ganancia de rendimiento)?

¿Cuál es la guía general para decidir si crear una nueva conexión o sesión si siempre me estoy conectando a la misma cola?

Gracias y lo siento por preguntar mucho a la vez.

(Aquí hay una pregunta similar, pero no respondía lo que estaba buscando. Sesiones JMS de larga duración. ¿Mantener las conexiones JMS / sesiones JMS siempre es una mala práctica? )

¿Está bien si algunos de los mensajes se duplican o se pierden? Cuando el cliente JMS se conecta con el intermediario JMS a través de la red, hay tres fases para cualquier llamada API.

La llamada API, incluidos los datos de mensajes, se transmite por el cable al intermediario.
La llamada API es ejecutada por el intermediario.
El código de resultado y cualquier dato de mensaje se transmiten de vuelta al cliente.

Considera al productor por un minuto. Si la conexión se rompe en el primer paso, entonces el intermediario nunca recibió el mensaje y la aplicación necesitaría enviarlo nuevamente. Si la conexión se interrumpe en el tercer paso, el mensaje se envió con éxito y enviarlo de nuevo generaría un mensaje duplicado. La aplicación no puede distinguir entre estos y la única opción segura es volver a enviar el mensaje por error. Si se tramita la sesión, el mensaje se puede reenviar de forma segura en todos los casos, porque si el original llegó al intermediario, se revertirá.

Considera al consumidor. Si la conexión se pierde en el tercer paso, entonces el mensaje se elimina de la cola pero nunca vuelve al cliente. Pero si se tramita la sesión, el mensaje se volverá a entregar cuando la aplicación se vuelva a conectar.

Fuera de las transacciones existe la posibilidad de mensajes perdidos o duplicados. Dentro de una transacción existe la misma ventana de ambigüedad, pero está en la llamada COMPRAR en lugar de en PUT o GET. Con las sesiones tramitadas, es posible enviar o recibir un mensaje dos veces pero no perder uno.

La especificación JMS reconoce esta ventana de ambigüedad y proporciona la siguiente guía:

Si se produce una falla entre el momento en que un cliente confirma su trabajo en una sesión y el método de confirmación regresa, el cliente no puede determinar si la transacción se cometió o revertió. La misma ambigüedad existe cuando se produce una falla entre el envío no transaccional de un mensaje PERSISTENT y el retorno del método de envío.
Depende de una aplicación JMS lidiar con esta ambigüedad. En algunos casos, esto puede hacer que un cliente produzca mensajes duplicados funcionalmente.
Un mensaje que se vuelve a entregar debido a la recuperación de la sesión no se considera un mensaje duplicado.

Las sesiones de JMS siempre se deben tramitar, excepto en los casos en los que realmente está bien perder mensajes. Si se tramitan las sesiones, necesitarás sesión y conexión por subproceso debido al modelo de subproceso JMS.

Cualquier consejo sobre los impactos en el rendimiento sería específico del proveedor, pero en general los mensajes persistentes fuera del punto de sincronización se endurecen en el disco antes de que regrese la llamada API. Pero una llamada transaccionada puede regresar antes de que el mensaje persistente se escriba en el disco, siempre y cuando el mensaje persista antes de que COMMIT regrese . Si el vendedor optimiza en función de esto, es mucho más eficiente escribir varios mensajes en el disco y luego enviarlos por lotes. Esto le permite al intermediario optimizar las escrituras y los vaciados de disco por bloque de disco en lugar de por mensaje. El número de mensajes para poner en la transacción disminuye con el tamaño del mensaje y más allá de cierto tamaño de mensaje se reduce a uno.

Si sus mensajes de 20k son relativamente pequeños (medidos en ky no en mb), entonces probablemente quiera usar sesiones transaccionadas por hilo y ajustar el intervalo de compromiso.

En la mayoría de los escenarios, es suficiente trabajar con una conexión y varias sesiones, usando una sesión por hilo. En algunos entornos, puede obtener un rendimiento adicional mediante el uso de conexiones múltiples:

Algunos sistemas de mensajería admiten un modo de clúster, donde las conexiones se equilibran en función de la carga con diferentes nodos. Con conexiones múltiples puede usar el rendimiento de múltiples nodos en este escenario. (que, por supuesto, solo ayuda, cuando el cuello de botella está del lado del intermediario de mensajes).

La mejor solución sería para nosotros un conjunto de conexiones, y le daremos al administrador algunas opciones para configurar el comportamiento en el área específica.

En teoría, las conexiones son seguras para subprocesos pero las demás no, por lo que debe crear una sesión por subproceso.

En realidad, depende de la implementación JMS que esté utilizando.

Por lo que investigo sobre este tema, una sesión significa un hilo. Esto se basa en las especificaciones de JMS. Si desea el enhebrado múltiple (múltiples productores / consumidores), es necesario crear varias sesiones, una conexión es adecuada.

I was wondering if having one connection, one session, and 10 producers is the recommended way to go or not?

Claro, pero tenga en cuenta aquí es que está utilizando un solo hilo, es decir, el que crea al crear el objeto de la sesión. Los 10 productores están vinculados a este objeto de sesión y, en consecuencia, al mismo hilo.

How about if I had one producer shared by all the threads? Would my messages be corrupt or would it be sent out synchronized (giving no performance gain)?

Muy mala idea, diría yo. Las especificaciones de JMS dicen claramente que la sesión no debe ser compartida por más de un hilo. No es seguro para subprocesos.

What''s the general guideline of deciding whether to create a new connection or session if I''m always connecting to the same queue?

Si su sistema admite multihebra, puede crear varias sesiones (cada sesión corresponde a un solo hilo) desde una única conexión. Cada sesión puede tener múltiples productores / consumidores, pero no todas deben compartirse entre hilos.