第 3 章 Sun GlassFish Communications Server 的已知問題與限制

本章說明 Communications Server 軟體的已知問題以及相關的解決方法。如果摘要敘述未指明特定的平台，則所有平台都可能出現此問題。這些資訊按以下章節進行分類：

• Communications Server 管理

• 整合負載平衡器

• 安裝

• 安全性

• SIP 容器

• SIP 階段作業複製

Communications Server 管理

Communications Server 不會偵測與叢集活動訊號連接埠的衝突 (問題編號 1967)

說明

叢集建立時，Communications Server 會為其隨機指定 1026 到 45556 之間的活動訊號連接埠。對於預設叢集 (亦即 Communications Server 安裝所建立的預設叢集)，系統會隨機選取介於 0 至 45556 之間的數字。叢集建立程序不會精確偵測是否已有其他服務使用該活動訊號連接埠。

解決方案

如果自動叢集建立配置選取了與另一服務 (已使用該連接埠) 衝突的活動訊號連接埠，請將叢集活動訊號連接埠更新為系統未使用的連接埠。

要變更叢集的活動訊號連接埠，請使用下列 asadmin 指令：

asadmin set cluster-name.heartbeat-port= newportnumber

執行 64 位元 Linux 的 NFS 伺服器停止建立網域 (問題編號 1961)

說明

在執行 64 位元 Linux 的 NFS 伺服器上，asadmin create-domain 指令在嘗試於掛載 Network File System (NFS) 的檔案系統上建立網域時可能會失敗。

解決方案

無已知解決方案。

流量極小或沒有流量時，CPU 使用率居高不下 (問題編號 1966)

說明

啟用了 CPU 超載保護時，即使在流量極小或沒有流量時，Communications Server 實例有時也會顯示很高的 CPU 使用量。這個問題是由於 JDK 錯誤所造成的： 6693490。這個錯誤已經在 JDK 6 Update 18 中解決。

解決方案

請將 JDK 6 Update 18 配合 Communications Server 使用。

在未連結 SIP/SIPS 連接埠的情況下，Communications Server 實例仍會啟動 (問題編號 998)

說明

在無法連結到 SIP 或 SIPS 連接埠的情況下，Communications Server 實例仍會啟動。

解決方案

請在啟動伺服器實例之前，確認連接埠可以使用。請檢查記錄檔 (server.log) 以確認啟動期間沒有發生過任何 SIP 容器錯誤或異常。

Communications Server 不會使用 ––javahome 選項所指定的 JDK (問題編號 789)

說明

您可以使用 ––javahome 選項，以預先安裝的 JDK 替代安裝的預設版本。依照預設，Communications Server 會使用來自 as-install/jdk 的 JDK 版本。

解決方案

asenv.conf 檔案中的 AS_JAVA 變數永遠會指向 as-install/jdk。如果您想要使用不同的 JDK 版本，請手動更新 asenv.conf 檔案並變更 AS_JAVA 的值。

使用 3.5 GB Java 堆疊會導致實例在收到流量時重新啟動 (問題 1169)

說明

當 JVM 堆疊大小設為 3.5 GB 時，如果接收到流量，Communications Server 實例會失敗並重新啟動。

解決方案

確認最大 JVM 堆疊大小已設為 3.0 GB 或更低。

僅使用多核心系統中的單一核心時，Communications Server 未正確報告 CPU 使用量 (問題 1344)

說明

在 Solaris 平台上，Communications Server 會根據可用的處理器數目和每個核心的 CPU 使用量，來計算 CPU 的使用量。然而，Communications Server 考量的是核心數目的靜態值，而非 JVM 所使用的核心數目。

解決方案

如果您沒有使用機器中的所有核心，請重新計算 CPU 臨界值。

整合負載平衡器

於應用程式部署後動態重新配置整合負載平衡器導致記錄檔中出現「發生嚴重問題」訊息 (問題 1161)

說明

如果您在目標機器上修改整合負載平衡器的配置，並於該目標機器上重新部署應用程式，則實例記錄檔會顯示「發生嚴重問題」訊息。

解決方案

這些訊息不會影響整合負載平衡器或實例的功能。您可以忽略這些訊息。

使用完整 URI 時，連絡標頭中的 BEKey 參數未正確換碼 (問題 1466)

說明

當您將整合負載平衡器配合會為 BEKey 參數傳回完整 URI 的資料導向規則檔案使用時，連絡標頭中的 BEKey 參數沒有正確換碼。「:」字元未依照 RFC 3261 中的指定正確換碼。

解決方案

無已知解決方案。

安裝

Communications Server 以檔案為基礎的安裝程式不會安裝 Basic3pcc 範例應用程式 (錯誤編號 6894932)

說明

Communications Server 以檔案為基礎的安裝程式不會安裝 Basic3pcc 範例應用程式。此應用程式會透過 JAR 安裝程式提供。

解決方案

無已知解決方案。

Communications Server 安裝程式在 Linux 上當機 (6739013)

說明

執行 Linux 的系統將環境變數 MALLOC_CHECK_ 設定為 2 時會出現此問題。

解決方案

將環境變數 MALLOC_CHECK_ 設定為 0。執行下列其中一個指令：

• 針對 Bourne shell：

  MALLOC_CHECK_=0; export MALLOC_CHECK_

• 針對 bash shell：

  export MALLOC_CHECK_=0

• 針對 csh、tcsh shell：

  setenv MALLOC_CHECK_ 0

64 位元 JDK 安裝失敗 (6796171)

說明

在具有 64 位元 JDK 的 64 位元系統上安裝失敗，因為安裝程式嘗試使用 64 位元 JDK。

解決方案

如果您想要在 64 位元系統上安裝 Sun GlassFish Communications Server，請下載 32 位元 JDK 以便在您的 64 位元機器上安裝 Sun GlassFish Communications Server。您需要使用下列指令：./distribution_filename —javahome 32 位元 JDK 位置路徑

安裝後，如果要確認 Sun GlassFish Communications Server 使用 64 位元 JDK，請在 asenv.conf 檔案中將 AS_JAVA 變數的值編輯為指向 64 位元 JDK 安裝。

安全性

Communications Server 在 sun-sip.xml 中未指定 trust-auth-realm-ref 屬性時丟出異常 (CR 6786131)

說明

在 sun-sip.xml 中配置 P-Asserted-Identity 認證時，Communications Server 丟出「未配置範圍」的空指標異常。

解決方案

請在 sun-sip.xml 中使用 trust-auth-realm-ref 屬性配置範圍。

SIP 容器

SIP 容器無法在已傳送 100 回應時處理取消請求 (問題 712)

說明

SIP 容器無法在已傳送 100 回應時處理取消請求。

解決方案

應用程式需要傳送暫時性的回應 (例如 1xx)，以便遠端能夠取消此 INVITE 請求。

SIP 階段作業和 HTTP 階段作業沒有套用相同的階段作業過期時間模型 (問題 1180)

說明

SIP 階段作業的階段作業過期模型和 HTTP 過期時間邏輯不同。在 HTTP 方面，每當在 HTTP 階段作業中接收到新的 HTTP 請求時，該階段作業會自動延伸，並不會受到應用程式的控制。

而在 SIP 階段作業方面，應用程式會在 SIP 容器的許可下，控制 SipApplicationSession (SAS) 的持續時間。應用程式可以使用 setExpires 方法指出 SAS 何時應過期。setExpires 會相對於呼叫 setExpires 方法的時間來定義過期時間。容器可以修改、拒絕或接受 setExpires 中所指出的持續時間。如果階段作業沒有失效，則會在 setExpires 定義的時間執行 sessionExpired 回呼。在此回呼中，應用程式可以嘗試呼叫新的 setExpires 以延伸 SAS 的持續時間，但仍會受到容器的修改、拒絕或接受控制。

因此，使用與 SipApplicationSession (SAS) 相同的過期時間啟動且位於 HTTP 階段作業的整合應用程式，在 HTTP 階段作業中接收到新的請求時，會發現 SAS 在 HTTP 階段作業前逾時。

解決方案

對於 SIP 和 HTTP 階段作業兩者不同的過期時間處理，最好的應付方式是啟動階段作業時使用夠長的 SAS 過期時間，此一過期時間即為應用程式階段作業預期存在 (包括數個 HTTP 請求) 的總時間長度。SAS 使用期限甚至可以設為無限，特別是使用 invalidateWhenReady 語義時，在這個情況下，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 階段作業仍持續 (問題 1265)

說明

這是偶爾會發生的問題。當指出階段作業已移除的 200 通知訊息，以及用戶端在收到該通知時所傳送的訂閱之間發生競爭情況時，SIP 容器偶爾會使用 500「伺服器內部錯誤」訊息回應，而非使用 481「呼叫/作業事件不存在」訊息回應。

解決方案

用戶端需要在訂閱到期前儘早更新訂閱。

Communications Server 會先後扮演 UAS 和代理的角色執行動作並產生 NOP (問題 1432)

說明

當它接收到邀請請求時，Communications Server 會先扮演 UAS 的角色，以 1XX 回覆此請求，然後會代理此邀請請求傳送給另一個實例，該實例會以 200「確定」訊息回覆。1xx 會建立內部虛擬分支，而 200 訊息會建立實際分支。在從 B 接收到 200「確定」訊息後，內部虛擬分支應會取消。

解決方案

此一異常追蹤不會影響虛擬代理分支的功能。

getLastAccessedTime 方法未提供精確的結果 (問題 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 偵聽程式在刪除後一段期間內仍維持作用中的狀態 (問題 1294)

說明

在刪除針對 TCP 和 UDP 請求所配置的 SIP 偵聽程式後，偵聽程式在一段期間內仍維持作用中的狀態。傳送給偵聽程式的 UDP 請求可能會接收到來自偵聽程式的回應。

解決方案

無已知解決方案。在一段時間之後，SIP 偵聽程式會停止偵聽 UDP 請求。這個問題並不會影響 TCP 請求。

Communications Server 在接收到不含「<>」的連絡標頭時丟出異常 (問題 1489)

說明

Communications Server 在接收到不含「<>」的連絡標頭時丟出異常。根據 SIP RFC 3261，位址中並非一定要使用「<>」。這可能會導致與其他 SIP 相容裝置間的互通性問題。

解決方案

請在使用連絡標頭中使用「<>」。

Communications Server 針對無效的 UUID 值丟出異常 (問題 1494)

說明

Communications Server 會針對無效的 UUID 值丟出異常，而非傳回 400「錯誤的請求」訊息。UUID 值位於 SIP 連絡標頭的 sip.instance 值之中。

解決方案

無已知解決方案。

Windows：有時 Communications Server 沒有收到 UDP 訊息 (無 ID)

說明

這是 Windows 作業系統上偶爾會發生的問題。Communications Server 沒有收到 UDP 訊息。

解決方案

將下列 JVM 選項依照下面的方式設定，並重新啟動 Communications Server。

org.jvnet.glassfish.comms.disableUDPSourcePort=true

SIP 階段作業複製

整合應用程式使用 SAS 物件做為同步化鎖定時可能發生死結情況 (問題編號 1954)

說明

如果具有 HTTP 和 SIP Servlet 的整合應用程式使用 sipApplicationSession 物件做為同步化 SIP 和 HTTP 背景工作執行緒之間存取的鎖定，會發生死結情況。

解決方案

請不要使用 sipApplicationSession 做為同步化鎖定。而是使用 sipApplicationSession 中設為屬性的可串列化物件做為鎖定。