ActiveMQメモリリーク - ヒープ内のオブジェクトの理解

Question

ActiveMQヒープサイズが連続的に増加しており、最終的にメモリが不足します。まだ実行されているインスタンスのヒープダンプを取得し、多くのインスタンスを持つ次のクラスを取得しました（残りのクラスはほとんど最小です）。ここで間違っている可能性のあるものについてのポインタを探しています。メッセージを送信するための

170866 instances of class org.apache.activemq.command.ProducerId 
170526 instances of class org.apache.activemq.broker.jmx.AnnotatedMBean 
170519 instances of class org.apache.activemq.command.SessionId 
170518 instances of class org.apache.activemq.command.ConnectionId 
170482 instances of class org.apache.activemq.broker.ProducerBrokerExchange 
170482 instances of class org.apache.activemq.broker.jmx.ProducerView 
170482 instances of class org.apache.activemq.command.ProducerInfo 
170482 instances of class org.apache.activemq.state.ProducerState 

コードスニペット：messageProducer.close()が欠落しているため

MessageProducer messageProducer = session.createProducer(topic); 
messageProducer.setTimeToLive(5 * 60 * 1000); 
Message message = session.createObjectMessage(agentDebugEvent); 
messageProducer.send(message); 

はありますか？

Answer 1

メッセージの送信ごとにプロデューサを作成し、それらをクローズしない場合は、プロデューサ用のJMX MBeanのビルドがJMXツリーに公開され、それぞれの作業を管理およびデバッグできます。もちろん、JMXをオフにするとオーバーヘッドは減少しますが、依然として添付されたプロデューサを追跡する必要があるため、ブローカの最終的な死に向かってゆっくりとクリープします。

JMSプールに切り替えることができ、リソースのプーリングが行われるため、送信者ごとにプロデューサを作成するように見えるようにすることができます単にキャッシュされた匿名プロデューサを使用します。現実には、これは一般的に貧弱な設計ですが、なぜこれらの線に沿って何かをする必要があると考えるのかを評価する必要があります。

MessageProducerを作成するには、ネットワーク上でラウンドトリップを行い、MBeanなどのブローカー側のリソースを作成するなどのコストがかかる操作です。送信者のパフォーマンスを探している場合は、1つのプロデューサを作成して再利用してください。