第 3 章 Sun GlassFish Communications Server の既知の問題点と制限事項

ここでは、Communications Server ソフトウェアに関する既知の問題とそれに関連する解決策について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この節は次の項目から構成されています。

• 「Communications Server の管理」

• 「融合ロードバランサ」

• 「インストール」

• 「セキュリティー」

• 「SIP コンテナ」

• 「SIP セッションレプリケーション」

Communications Server の管理

Communications Server がクラスタのハートビートポートの競合を検出しない (Issue Number 1967)

説明

クラスタを作成するときに、Communications Server はハートビートポートを 1026 - 45556 の間でランダムに割り当てます。default-cluster (Communications Server のインストールが作成するデフォルトのクラスタ) では、0 - 45556 のランダムな数字が選択されます。クラスタの作成プロセスは、ハートビートポートがすでに別のサービスで使用されているかどうかを正確に検出しません。

解決方法

自動クラスタ作成の設定で選択されるハートビートポートが、すでにそのポートを使用している別のサービスと競合する場合は、クラスタのハートビートポートをシステムが使用していないポートに更新します。

クラスタのハートビートポートを変更するには、次の asadmin コマンドを使用します。

asadmin set cluster-name.heartbeat-port= newportnumber

64 ビット Linux で動作している NFS サーバーで、ドメインの作成が停止する (Issue Number 1961)

説明

64 ビット Linux で動作している NFS サーバーで、NFS (ネットワークファイルシステム) マウント済みファイルシステム上にドメインを作成しているときに、asadmin create-domain コマンドが失敗する場合があります。

解決方法

現在のところ解決策はありません。

トラフィックが非常に少ないかまったくない場合に、CPU 使用量が高い (Issue Number 1966)

説明

CPU 過負荷保護が有効になっている場合に、トラフィックが非常に少ないかまったくないのに、Communications Server のインスタンスが高い CPU 使用量を示すことがあります。この問題は、JDK バグ 6693490 が原因で発生します。 このバグは JDK 6 Update 18 で解決されています。

解決方法

&ProductName で JDK 6 Update 18 を使用してください。

SIP/SIPS ポートがバインドされなくても Communications Server インスタンスが起動する (Issue Number 998)

説明

SIP または SIPS ポートをバインドできない場合でも、Communications Server インスタンスが起動します。

解決方法

サーバーインスタンスを起動する前に、ポートが開放されていることを確認します。ログファイル (server.log) で、起動時に SIP コンテナのエラーや例外が発生していないことを確認します。

Communications Server が、––javahome オプションで指定した JDK を使用しない (Issue Number 789)

説明

––javahome オプションを使用すると、デフォルトのバージョンの代わりにインストール済みの JDK をインストールで使用できます。デフォルトでは、Communications Server は as-install/jdk の JDK バージョンを使用します。

解決方法

asenv.conf ファイルの AS_JAVA 変数は、常に as-install/jdk をポイントします。別のバージョンの JDK を使用する場合は、asenv.conf ファイルを手動で更新し、AS_JAVA の値を変更します。

3.5G バイトの Java ヒープを使用すると、トラフィックが存在する間にインスタンスが再起動する (Issue 1169)

説明

JVM ヒープサイズが 3.5G バイトに設定されている場合、トラフィックを受信するとインスタンスでエラーが発生し再起動します。

解決方法

最大の JVM ヒープサイズが 3.0G バイト以下に設定されていることを確認します。

マルチコアシステムで 1 つのコアだけを使用しているときに、Communications Server による CPU 使用状況のレポートが正しくない (Issue 1344)

説明

Solaris プラットフォームでは、Communications Server は CPU 使用状況を、利用可能なプロセッサの数とコアごとの CPU 使用状況に基づいて計算します。このとき、Communications Server は JVM が使用しているコアの数ではなく、コアの数の静的な値を使用して計算を行います。

解決方法

マシンのすべてのコアが使用されていない場合は、CPU のしきい値を再計算してください。

融合ロードバランサ

アプリケーション配備のあとに融合ロードバランサの動的再構成によって、ログに SEVERE メッセージが記録される (Issue 1161)

説明

ターゲットで融合ロードバランサの構成を変更してアプリケーションを再配備する場合、インスタンスのログに SEVERE メッセージが記録されます。

解決方法

これらのメッセージは、融合ロードバランサやその他のインスタンスの動作に影響しません。メッセージを無視してください。

完全 URI を使用すると、Contact ヘッダーの BEKey パラメータが正しくエスケープされない (Issue 1466)

説明

融合ロードバランサで、BEKey パラメータに完全な URI を返すデータ中心ルールファイルを使用すると、Contact ヘッダーの BEKey パラメータが正しくエスケープされません。RFC 3261 で説明されているように、「:」文字は正しくエスケープされません。

解決方法

現在のところ解決策はありません。

インストール

Communications Server のファイルベースインストーラが Basic3pcc サンプルアプリケーションをインストールしない (バグ番号 6894932)

説明

Communications Server のファイルベースインストーラは Basic3pcc サンプルアプリケーションをインストールしません。このアプリケーションは JAR インストーラで利用可能になります。

解決方法

現在のところ解決策はありません。

Communications Server インストーラが Linux でクラッシュする (6739013)

説明

この問題は、環境変数 MALLOC_CHECK_ に 2 を設定して Linux を実行しているシステムで観察されています。

解決方法

環境変数 MALLOC_CHECK_ を 0 に設定してください。次のいずれかのコマンドを実行します。

• Bourne シェルの場合

  MALLOC_CHECK_=0; export MALLOC_CHECK_

• bash シェルの場合

  export MALLOC_CHECK_=0

• csh、tcsh シェルの場合

  setenv MALLOC_CHECK_ 0

64 ビット JDK によるインストールが失敗する (6796171)

説明

64 ビット JDK をインストールしている 64 ビットシステムでは、インストーラが 64 ビット JDK の使用を試みるため、インストールが失敗します。

解決方法

Sun GlassFish Communications Server を 64 ビットシステムにインストールする場合は、使用している 64 ビットマシンで 32 ビット JDK をダウンロードし、この JDK を使用して Sun GlassFish Communications Server をインストールしてください。次のコマンドを使用する必要があります。 ./distribution_filename —javahome path to 32–bit JDK location

インストールのあと、Sun GlassFish Communications Server で 64 ビット JDK を使用するには、asenv.conf ファイルの AS_JAVA 変数を、64 ビット JDK のインストールをポイントするように編集します。

セキュリティー

trust-auth-realm-ref プロパティーが sun-sip.xml に指定されていない場合、Communications Server が例外をスローする (CR 6786131)

説明

sun-sip.xml で P-Asserted-Identity が設定されているときに、レルムが設定されていないと、Communications Server が Null ポインタの例外をスローします。

解決方法

sun-sip.xml で trust-auth-realm-ref プロパティーを使用してレルムを設定します。

SIP コンテナ

SIP コンテナが 100 の応答を送信したときに CANCEL を処理できない (Issue 712)

説明

100 の応答が送信された場合、SIP コンテナは CANCEL 要求を処理できません。

解決法

アプリケーションはプロビジョナルな応答 (1xx など) を送信して、リモート側が INVITE 要求に対して CANCEL を実行できるようにする必要があります。

SIP セッションおよび HTTP セッションに、同じセッション有効期限モデルが適用されない (Issue 1180)

説明

SIP セッションのセッション有効期限モデルは、HTTP の有効期限ロジックと異なります。HTTP の場合、HTTP セッション内で新しい HTTP 要求を受信すると、アプリケーションによる制御を必要とせずに、自動的にセッションが延長されます。

SIP セッションの場合、SIP コンテナによって許可されれば、アプリケーションが SipApplicationSession (SAS) の期間を管理します。アプリケーションは setExpires メソッドを使用して、SAS の有効期限を指定できます。setExpires は、setExpires メソッドが呼び出された時点からの相対時間で有効期限を定義します。コンテナは、setExpires で指定された期限を変更、拒否、または承諾することができます。セッションが無効になっていない場合は、setExpires で定義された時間に、sessionExpired のコールバックが実行されます。このコールバックで、再度コンテナによって変更、拒否、または承諾されれば、アプリケーションは新しい setExpires を呼び出して、SAS の期限の延長を試みることができます。

このため、HTTP セッション上で同じ有効期限の SipApplicationSession (SAS) で開始される融合アプリケーションは、HTTP セッションが新しいリクエストを受信した場合、HTTP セッションの前に SAS の有効期限が切れることを通知されます。

解決方法

SIP セッションおよび HTTP セッションを処理する有効期限が異なる場合は、アプリケーションセッションが存続すると予想される (いくつかの HTTP リクエストを含む)、十分な長さの SAS 有効期限を指定して開始することが最善の方法です。特に、invalidateWhenReady セマンティクスが使用されている場合は、SAS の有効期限を無期限に設定することもできます。この場合、最後のプロトコルの子セッションが無効になるときに、SipApplicationSession が無効になります。SAS の初期有効期限は、配備記述子で設定できます。

最大の総期間を前もって予測できて、追加のコードが必要ない場合は、SAS の期限が切れるときに SIP セッションと HTTP セッションの両方を無効にするのが適切です。最大期間を予測できない場合は、次のコードスニペットのように、SipApplicationSession を延長できます。

SipApplicationSessionListener の実装で、次のような処理を行えます。

public void sessionExpired(SipApplicationSessionEvent sasEvent) {
                // check if the SAS needs to be extended first, if so:
		int granted = sasEvent.getApplicationSession().setExpires(2);
		if (granted <= 0) {
			System.out.println("extension rejected");
		} else if (granted < 2) {
			System.out.println("extension granted with lower value " + granted);
		} // else allowed 
	}

コンテナが sessionExpired にコールバックしたあとに SIP セッションが存続する (Issue 1265)

説明

これはときどき発生する問題です。セッションが削除されていることを示す NOTIFY に対する 200 と、NOTIFY を受信したときにクライアントが送信する SUBSCRIBE に競合状態がある場合、SIP コンテナは、「481 Call/Transaction does not exist」メッセージの代わりに「500 Server internal error」メッセージを返すことがあります。

解決方法

クライアントはサブスクリプションが期限切れになる前に、SUBSCRIBE を更新する必要があります。

Communications Server が最初に UAS として、続いてプロキシとして動作し、NOP を生成する (Issue 1432)

説明

Communications Server は INVITE リクエストを受信すると、最初に UAS として動作し、このリクエストに 1XX で応答します。次に、この INVITE リクエストを別のインスタンスにプロキシ処理し、このインスタンスが 200 OK で応答します。1xx は内部仮想ブランチを作成しますが、200 メッセージは実ブランチを作成します。B から 200 OK を受信したら、内部仮想ブランチは取り消されるべきです。

解決方法

この例外トレースは、仮想プロキシブランチの動作に影響しません。

getLastAccessedTime メソッドが正確な結果を返さない (Issue 1351)

説明

SIP セッションの getLastAccessedTime メソッドが、正確な結果を返しません。

解決方法

lastAccessedTime を正確に追跡する必要があるアプリケーションは、自身でこれを SipApplicationSession に保存する必要があります。

synchronized (sas) {
	Long last = (Long) sas.getAttribute("myLastAccessedTime");
	if (last == null) {last = 0};
	// do something with the last one
	// and...
	// set the new one.
	sas.setAttribute("myLastAccessedTime", System.currentTimeMillis());
}

削除した SIP リスナーが一定期間アクティブなままになる (Issue 1249)

説明

TCP および UDP リクエストに対して設定した SIP リスナーを削除したあと、リスナーが一定期間アクティブなままになります。リスナーに送信された UDP リクエストが、リスナーからの応答を受信する場合があります。

解決方法

現在のところ解決策はありません。SIP リスナーは一定期間のあと、UDP リクエストの待機を終了します。この問題は TCP リクエストには影響しません。

「<>」のない Contact ヘッダーを受信すると、Communications Server が例外をスローする (Issue 1489)

説明

Communications Server は、「<>」がない Contact ヘッダーを受信したときに例外をスローします。SIP RFC 3261 では、アドレスでの「<>」の使用は必須ではありません。これにより、ほかの SIP 互換デバイスで相互運用性の問題が発生する場合があります。

解決法

Contact ヘッダーでは「<>」を使用してください。

無効な UUID 値で Communications Server が例外をスローする (Issue 1494)

説明

Communications Server は、無効な UUID 値で 400 Bad Request を返す代わりに例外をスローします。UUID 値は SIP Contact ヘッダーの sip.instance 値にあります。

解決方法

現在のところ解決策はありません。

Windows: Communications Server で UDP メッセージが受信されない (ID なし)

説明

この問題は Windows のみで、ときどき発生します。UDP メッセージが Communications Server で受信されません。

解決方法

JVM オプションを次のように設定して、Communications Server を再起動します。

org.jvnet.glassfish.comms.disableUDPSourcePort=true

SIP セッションレプリケーション

融合アプリケーションが SAS オブジェクトを同期ロックとして使用すると、デッドロックの可能性がある (Issue Number 1954)

説明

HTTP および SIP サーブレットを持つ融合アプリケーションが sipApplicationSession オブジェクトをロックとして使用して、SIP および HTTP ワークスレッド間のアクセスを同期させている場合、デッドロックが起こります。

解決方法

sipApplicationSession を同期ロックとして使用しないでください。その代わり、Serializable オブジェクトを sipApplicationSession で属性として設定して、ロックとして使用してください。