PooledConnectionFactoryとCachingConnectionFactoryのどちらが良いですか？
Tomcat（7.0.41）のActiveMQ（5.8.0）でSpring（3.2.4）を使用しますが、どのような使用法が最適かは明確ではありません。 JmsTemplateを使用してメッセージを生成し、MessageListenerContainerを使用してメッセージを受信します。
受信側でキャッシュを使用する必要がありますか？ （ 関連リンク ）
ActiveMQとフェイルオーバーを備えたWorks CachingConnectionFactory？ （ 関連リンク ）
PooledConnectionFactoryを使用するときにuseAsyncSend = "true"を設定する必要がありますか？ （ 関連リンク ）
ここ から：
PooledConnectionFactoryとCachingConnectionFactoryの違いは、実装の違いです。以下は、それらの間で異なるいくつかの特性です。
PooledConnectionFactoryとCachingConnectionFactoryの両方は、それぞれが接続、セッション、およびプロデューサーをプールしていると述べていますが、実際にはPooledConnectionFactoryは複数のプロデューサーのキャッシュを作成しません。単一のパターンを使用して、要求されたときに単一のキャッシュされたプロデューサーを配布します。一方、CachingConnectionFactoryは複数のプロデューサーを含むキャッシュを実際に作成し、1つのプロデューサーが要求されたときにキャッシュから1つのプロデューサーを配布します。
PooledConnectionFactoryは、JMSセッションをプールするためのApache Commons Poolプロジェクトの上に構築されています。これにより、PooledConnectionFactoryによって使用されていない機能がCommons Poolにあるため、プールをさらに制御できます。これらの追加機能には、ブロックの代わりにプールサイズを大きくする、プールが使い果たされたときに例外をスローするなどが含まれます。 setPoolFactoryメソッド。追加情報については、以下を参照してください。 http://commons.Apache.org/pool/api-1.4/org/Apache/commons/pool/impl/GenericObjectPoolFactory.html
CachingConnectionFactoryには、コンシューマもキャッシュする機能があります。この機能を使用するときは、ブログ投稿に記載されているルールに従って消費者がキャッシュされることを知っておく必要があります。
しかし最も重要なことは、CachingConnectionFactoryはJMS準拠のMOMで動作します。 JMS接続ファクトリーのみが必要です。これは、企業組織で非常に一般的な複数のMOMベンダーを使用している場合に重要です（これは主にレガシーおよび既存のプロジェクトによるものです）。重要な点は、CachingConnectionFactoryはActiveMQだけでなく、多くの異なるMOM実装で非常にうまく機能することです。
ここ から：
ActiveMQをクラスター化し、フェールオーバートランスポートを使用している場合、CachingConnectionFactoryは正しい選択ではないことが報告されています。
私が抱えている問題は、1つのボックスがダウンした場合、他のボックスでメッセージの送信を開始する必要があるが、それでも古い接続を使用しているように見えることです（すべての送信タイムアウト）。プログラムを再起動すると、再び接続され、すべてが機能します。ソース： ActiveMQおよびCachingConnectionFactoryの自動再接続の問題
問題は、障害が発生したActiveMQへのキャッシュされた接続がまだ使用中であり、それがユーザーに問題を引き起こしたことです。現在、このシナリオの選択肢はPooledConnectionFactoryです。
現在ActiveMQを使用しており、将来的に他のブローカー（JBoss MQ、WebSphere MQ）に切り替える可能性がある場合は、PooledConnectionFactoryを使用しないでください。 ActiveMQ。