0

(tibjms 4.4.3 ライブラリを使用して) Tibco トピックから消費すると、Camel (2.10.3) で非常に奇妙なメモリ リークが発生します。ヒープ ダンプを見ると、メモリ消費量が膨大な量の ConcurrentHashMap のもの (セグメント、HashEntry[]、ロックなど) であることがわかります。

私が信じているのは、トピックからの交換が Camel によって「完了」としてマークされることは決してなく、それらへの参照がメモリ内に保持されているということです。それらを「.stop()」にルーティングすると、問題はなくなります。

以下を使用して JMS コンポーネントを作成します。

    TibjmsConnectionFactory connectionFactory = new TibjmsConnectionFactory();
    connectionFactory.setServerUrl(properties.getProperty(endpoints.getServerUrl()));
    connectionFactory.setUserName(properties.getProperty(endpoints.getUsername()));
    connectionFactory.setUserPassword(properties.getProperty(endpoints.getPassword()));

    JmsComponent emsComponent = JmsComponent.jmsComponent(connectionFactory);

    return emsComponent;

次のようにコンテキストに登録します。

    camelContext.addComponent("positionems", emsComponent);

次に、問題を再現するためだけに、信じられないほど単純なテスト ルートを作成しました。

    from("positionems:topic:UK.TOPIC4")
    .to("mock:out");

興味深いのは、プロセスが Heap Space エラーで失敗するまで、ConcurrentHashMap でヒープがいっぱいになることです。しかし、ルートを次のように変更すると、永遠に問題なく動作します。

    from("positionems:topic:UK.TOPIC4")
    .stop();

stop の javadoc によると、「現在の org.apache.camel.Exchange のルーティングを停止し、完了としてマークします」。-おそらく「完了としてマーク」は、モックに送信するときに欠落しているものです（または、実際に完全な通常のプログラムを実行すると、メモリに関してモックに送信するのと同じように動作します）。

たとえば、Jms ルート構成のさまざまなバリエーションを試しました。

    from("positionems:topic:UK.TOPIC4?disableReplyTo=true&deliveryPersistent=false")

そして、応答を期待しないようにルートを設定しようとしましたが、おそらくこれは間違っています:

    from("positionems:topic:UK.TOPIC4")
    .inOnly()         // marked as deprecated?
    .to("mock:out");

これは Tibco に固有の問題ですか? 問題なく ActiveMQ を使用している人の数を考えると、Camel で実際のバグを発見したとは信じがたいと思います。うまくいけば、私は本当に単純な間違いを犯しています!

編集

私は最新の Camel バージョン (2.12.1) でテストしましたが、これは少し良くなっているように見えます (ConcurrentHashMap セグメントの数が遅くなります) が、それでも問題はあります。

4

1 に答える 1