第9章 デッド接続の検出


クライアントが予期せずに停止し、それらのリソースをクリーンアップする機会がないことがあります。これが発生すると、リソースが faulty 状態のままになり、ブローカーがメモリー不足または他のシステムリソースで実行されている可能性があります。ブローカーは、ガベージコレクション時にクライアントの接続が適切にシャットダウンされなかったことを検出します。その後、コネクションは閉じられ、以下のようなメッセージがログに書き込まれます。ログは、クライアントセッションがインスタンス化されたコードの正確な行を取得します。これにより、エラーを特定し、これを修正できます。

[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession]  I'm closing a JMS Conection you left open. Please make sure you close all connections explicitly before let
ting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession]  The session you didn't close was created here:
java.lang.Exception
   at org.apache.activemq.artemis.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
   at org.acme.yourproject.YourClass (YourClass.java:666) 1
1
接続がインスタンス化されたクライアントコードの行。

クライアント側からのデッド接続の検出

ブローカーからデータを受信する限り、クライアントは接続がアライブ状態であると判断します。client-failure-check-period プロパティーの値を指定して、接続の失敗を確認するようにクライアントを設定します。ネットワーク接続のデフォルトのチェック期間は 30000 ミリ秒で、In-VM 接続のデフォルト値は -1 です。これは、データが受信されなかった場合、クライアントがその側から接続を失敗させないことを意味します。

通常、チェック期間はブローカーの接続の Time-to-live に使用される値よりもはるかに低い値に設定し、一時的な障害が発生した場合にクライアントが再接続できるようにします。

以下の例は、Core JMS クライアントを使用してチェック期間を 10000 ミリ秒に設定する方法を示しています。

手順

  • デッド接続を検出するためのチェック期間を設定します。

    • Core JMS クライアントで JNDI を使用している場合は、以下のように JNDI コンテキスト環境 (jndi.properties) 内のチェック期間を設定します。

      java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
      connectionFactory.myConnectionFactory=tcp://localhost:61616?clientFailureCheckPeriod=10000
    • JNDI を使用していない場合は、値を ActiveMQConnectionFactory.setClientFailureCheckPeriod() に渡してチェック期間を直接設定します。

      ConnectionFactory cf =  ActiveMQJMSClient.createConnectionFactory(...)
      cf.setClientFailureCheckPeriod(10000);

9.1. 接続 Time-To-Live

クライアントとサーバー間のネットワーク接続に失敗してオンラインに戻る可能性があるため、AMQ Broker は非アクティブなサーバー側のリソースをクリーンアップします。この待機時間は Time-to-live (TTL) と呼ばれます。ネットワークベースの接続のデフォルトの TTL は 60000 ミリ秒 (1 分 ) です。in-VM 接続のデフォルトの TTL は -1 です。つまり、ブローカーはブローカー側で接続をタイムアウトしません。

ブローカーでの Time-To-Live の設定

クライアントが独自の接続 TTL を指定しないようにするには、ブローカー側でグローバル値を設定します。これは、ブローカー設定で connection-ttl-override 要素を指定して実行できます。

connection-ttl-check-interval 要素によって決定されるように、TTL 違反の接続をチェックするロジックはブローカーで定期的に実行されます。

手順

  • 以下の例のように、BROKER_INSTANCE_DIR/etc/broker.xml を編集して connection-ttl-override 設定要素を追加し、time-to-live の値を指定します。

    <configuration>
     <core>
      ...
      <connection-ttl-override>30000</connection-ttl-override> 1
      <connection-ttl-check-interval>1000</connection-ttl-check-interval> 2
      ...
     </core>
    </configuration>
    1
    すべての接続のグローバル TTL は 30000 ミリ秒に設定されます。デフォルト値は -1 で、クライアントが独自の TTL を設定できるようにします。
    2
    デッド接続をチェックする間隔は 1000 ミリ秒に設定されます。デフォルトでは、チェックは 2000 ミリ秒ごとに行われます。

クライアント上での Time-To-Live の設定

デフォルトでは、クライアントは独自の接続に TTL を設定できます。以下の例は、Core JMS クライアントを使用して Time-To-Live を設定する方法を示しています。

手順

  • クライアント接続に Time-To-Live を設定します。

    • JNDI を使用して接続ファクトリーをインスタンス化する場合は、connectionTTL パラメーターを使用して xml 設定に指定できます。

      java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
      connectionFactory.myConnectionFactory=tcp://localhost:61616?connectionTTL=30000
    • JNDI を使用していない場合は、接続 TTL は ActiveMQConnectionFactory インスタンスの ConnectionTTL 属性によって定義されます。

      ConnectionFactory cf =  ActiveMQJMSClient.createConnectionFactory(...)
      cf.setConnectionTTL(30000);
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.