Quel est le meilleur: PooledConnectionFactory ou CachingConnectionFactory?
Nous utilisons Spring (3.2.4) avec ActiveMQ (5.8.0) dans Tomcat (7.0.41) et nous ne savons pas quelle est la meilleure utilisation. Nous voulons utiliser JmsTemplate pour produire et MessageListenerContainer pour recevoir des messages.
Devrions-nous utiliser la mise en cache côté récepteur? ( lien connexe )
Fonctionne CachingConnectionFactory avec ActiveMQ et le basculement? ( lien connexe )
Besoin de définir useAsyncSend = "true" lorsque nous utilisons PooledConnectionFactory? ( lien connexe )
De ici :
La différence entre PooledConnectionFactory et CachingConnectionFactory est une différence d'implémentation. Voici quelques-unes des caractéristiques qui diffèrent entre elles:
Bien que PooledConnectionFactory et CachingConnectionFactory indiquent qu'ils regroupent chacun des connexions, des sessions et des producteurs, le PooledConnectionFactory ne crée pas réellement de cache de plusieurs producteurs. Il utilise simplement un modèle singleton pour distribuer un seul producteur en cache lorsque celui-ci est demandé. Alors que CachingConnectionFactory crée en fait un cache contenant plusieurs producteurs et distribue un producteur du cache quand un est demandé.
PooledConnectionFactory est construit sur le projet Apache Commons Pool pour la mise en commun des sessions JMS. Cela permet un contrôle supplémentaire sur le pool car il existe des fonctionnalités dans Commons Pool qui ne sont pas utilisées par PooledConnectionFactory. Ces fonctionnalités supplémentaires incluent l'augmentation de la taille du pool au lieu de bloquer, le lancement d'une exception lorsque le pool est épuisé, etc. Vous pouvez utiliser ces fonctionnalités en créant votre propre pool commun GenericObjectPool en utilisant vos propres paramètres personnalisés, puis en remettant cet objet à PooledConnectionFactory via le Méthode setPoolFactory. Voir les informations suivantes pour plus d'informations: http://commons.Apache.org/pool/api-1.4/org/Apache/commons/pool/impl/GenericObjectPoolFactory.html
CachingConnectionFactory peut également mettre en cache les consommateurs. Il suffit de faire attention lors de l'utilisation de cette fonctionnalité pour que vous sachiez que les consommateurs sont mis en cache selon les règles notées dans le blog.
Mais le plus important, CachingConnectionFactory fonctionnera avec n'importe quel MOM compatible JMS. Il ne nécessite qu'une fabrique de connexions JMS. Ceci est important si vous utilisez plus d'un fournisseur MOM, ce qui est très courant dans les organisations d'entreprise (cela est principalement dû aux projets existants et existants). Le point important est que CachingConnectionFactory fonctionne très bien avec de nombreuses implémentations MOM différentes, pas seulement ActiveMQ.
De ici :
Si vous avez mis en cluster des ActiveMQ et utilisez le transport de basculement, il a été signalé que CachingConnectionFactory n'est pas un bon choix.
Le problème que j'ai, c'est que si une case tombe en panne, nous devrions commencer à envoyer des messages sur l'autre, mais il semble qu'elle utilise toujours l'ancienne connexion (chaque expiration du délai d'envoi). Si je redémarre le programme, il se connectera à nouveau et tout fonctionnera. Source: problème de reconnexion automatique avec ActiveMQ et CachingConnectionFactory
Le problème est que les connexions mises en cache à ActiveMQ en échec étaient toujours en cours d'utilisation et que cela a créé le problème pour l'utilisateur. Maintenant, le choix pour ce scénario est PooledConnectionFactory.
Si vous utilisez ActiveMQ aujourd'hui et qu'il est probable que vous puissiez passer à un autre courtier (JBoss MQ, WebSphere MQ) à l'avenir, n'utilisez pas PooledConnectionFactory, car il couple étroitement votre code à ActiveMQ.