java - example - ¿Qué es mejor: PooledConnectionFactory o CachingConnectionFactory?

spring jms weblogic

Question

Usamos Spring (3.2.4) con ActiveMQ (5.8.0) en Tomcat (7.0.41) y no está claro cuál es el mejor uso. Queremos usar JmsTemplate para producir y MessageListenerContainer para recibir mensajes.

¿Debemos usar el caché en el lado del receptor? ( enlace relacionado )
¿Funciona CachingConnectionFactory con ActiveMQ y failover? ( enlace relacionado )
¿Necesitas establecer useAsyncSend = "true" cuando usamos PooledConnectionFactory? ( enlace relacionado )

Answer 1

Desde here

La diferencia entre PooledConnectionFactory y CachingConnectionFactory es una diferencia en la implementación. A continuación se presentan algunas de las características que difieren entre ellas:

• Aunque tanto PooledConnectionFactory como CachingConnectionFactory afirman que agrupan conexiones, sesiones y productores, PooledConnectionFactory no crea realmente un caché de múltiples productores. Simplemente utiliza un patrón de singleton para entregar un solo productor en caché cuando se solicita uno. Mientras que CachingConnectionFactory en realidad crea un caché que contiene múltiples productores y reparte un productor del caché cuando se solicita uno.

• El PooledConnectionFactory está construido sobre el proyecto de Apache Commons Pool para agrupar sesiones JMS. Esto permite cierto control adicional sobre el grupo porque hay características en el grupo de campos comunes que no están siendo utilizadas por PooledConnectionFactory. Estas características adicionales incluyen aumentar el tamaño del grupo en lugar de bloquearlo, lanzar una excepción cuando se agote el grupo, etc. Puede utilizar estas funciones creando su propio Commons Pool GenericObjectPool usando sus propias configuraciones personalizadas y luego entregando ese objeto a PooledConnectionFactory a través de Método setPoolFactory. Vea lo siguiente para obtener información adicional: http://commons.apache.org/pool/api-1.4/org/apache/commons/pool/impl/GenericObjectPoolFactory.html

• El CachingConnectionFactory tiene la capacidad de también almacenar en caché a los consumidores. Solo debes tener cuidado al usar esta función para que sepas que los consumidores se almacenan en caché de acuerdo con las reglas anotadas en la publicación del blog.

• Pero lo más importante, CachingConnectionFactory funcionará con cualquier MOM compatible con JMS. Solo requiere una fábrica de conexiones JMS. Esto es importante si está utilizando más de un proveedor de MOM, lo cual es muy común en las organizaciones empresariales (esto se debe principalmente a proyectos existentes y heredados). El punto importante es que CachingConnectionFactory funciona muy bien con muchas implementaciones MOM diferentes, no solo ActiveMQ.

Desde here

• Si ha agrupado ActiveMQs y utiliza transporte de conmutación por error, se ha informado que CachingConnectionFactory no es una opción correcta.

• El problema que tengo es que si una casilla se cae, deberíamos comenzar a enviar mensajes en la otra, pero parece que todavía está usando la conexión anterior (cada tiempo de envío se agota). Si reinicio el programa, se conectará de nuevo y todo funcionará. Fuente: Problema de conexión automática con ActiveMQ y CachingConnectionFactory

• El problema es que las conexiones en caché de ActiveMQ fallidas aún estaban en uso y eso creó el problema para el usuario. Ahora, la opción para este escenario es PooledConnectionFactory.

• Si está utilizando ActiveMQ hoy, y es probable que pueda cambiar a otro agente (JBoss MQ, WebSphere MQ) en el futuro, no use PooledConnectionFactory, ya que combina su código con ActiveMQ.