Kapitel 3 Sun GlassFish Communications Server Bekannte Probleme und Einschränkungen

In diesem Kapitel werden bekannte Probleme und die zugehörigen Abhilfemaßnahmen für die Software &; Communications Server erläutert. Wenn für ein Problem keine spezielle Plattform angegeben ist, betrifft es alle Plattformen. Die hier gegebenen Informationen sind wie folgt unterteilt:

• Administration von Communications Server

• Konvergierter Lastenausgleich

• Installation

• Sicherheit

• SIP-Container

• SIP-Sitzungsreplikation

Administration von Communications Server

Communications Server erkennt keine Probleme mit dem Heartbeat-Port eines Clusters (Problem 1967)

Beschreibung

Bei der Erstellung eines Clusters weist Communications Server einen zufälligen Heartbeat-Port zwischen 1026 und 45556 zu. Bei·default-cluster, dem von einer Communications Server-Installation erstellten Standard-Cluster, wird eine Zufallszahl zwischen 0 und 45556 gewählt. Bei der Cluster-Erstellung wird nicht präzise erkannt, ob der Heartbeat-Port bereits von einem anderen Dienst verwendet wird.

Lösung

Wenn bei der automatisierten Cluster-Erstellungskonfiguration ein Heartbeat-Port gewählt wird, der im Konflikt zu einem anderen Dienst steht, der bereits diesen Port verwendet, aktualisieren Sie den Heartbeat-Port des Clusters in einen Port, der nicht vom System verwendet wird.

Um den Heartbeat-Port eines Clusters zu ändern, verwenden Sie den folgenden asadmin-Befehl:

asadmin set Cluster-Name.heartbeat-port= neuePortNummer

Domänenerstellung stoppt auf NFS-Server, der 64-Bit-Linux ausführt (Problem 1961)

Beschreibung

Der Befehl asadmin create-domain kann während des Versuchs, eine Domäne in einem von NFS eingehängten Dateisystem (Network File System, NFS = Netzwerkdateisystem) mit einem 64-Bit-Linux ausführenden NFS-Server zu erstellen, fehlschlagen.

Lösung

Keine bekannte Lösung.

Hohe CPU-Auslastung bei keinem oder wenig Datenverkehr (Problem Nummer 1966)

Beschreibung

Communications Server-Instanzen zeigen manchmal eine hohe CPU-Auslastung, selbst bei wenig oder keinem Datenverkehr, wenn der CPU-Überlastungsschutz aktiviert ist. Der Grund für dieses Problem ist der JDK-Fehler 6693490. Dieser Fehler wurde in JDK 6 mit Update 18 behoben.

Lösung

Verwenden Sie JDK 6 mit Update 18 mit Communications Server.

Communications Server-Instanzen starten auch, wenn SIP/SIPS-Ports nicht gebunden sind (Problem Nummer 998)

Beschreibung

Communications Server-Instanzen starten auch, wenn keine Verbindung zu einem SIP- oder SIPS-Port hergestellt werden kann.

Lösung

Stellen Sie vor dem Starten von Serverinstanzen sicher, dass Ports verfügbar sind. Überprüfen Sie die Protokolldateien (server.log), um sicherzugehen, dass während des Startvorgangs keine SIP-Container-Fehler oder -Ausnahmen aufgetreten sind.

Communications Server verwendet die durch die Option ––javahome spezifizierte JDK nicht (Problem 789)

Beschreibung

Mit der Option ––javahome können Sie eine vorinstallierte Version von JDK anstatt der Standardversion für die Installation verwenden. Communications Server verwendet standardmäßig die JDK-Version aus as-install/jdk.

Lösung

Die Variable AS_JAVA in der Datei asenv.conf weist immer auf as-install/jdk hin. Wenn Sie eine andere JDK-Version verwenden möchten, aktualisieren Sie die Datei asenv.conf manuell und ändern Sie den Wert AS_JAVA.

Bei Verwendung von Java-Heap mit 3,5 GB starten Instanzen neu, während Datenverkehr stattfindet (Problem 1169)

Beschreibung

Wenn die Größe des JVM-Heap auf 3,5 GB eingestellt ist, schlagen Instanzen fehl und starten neu, wenn Sie Daten empfangen.

Lösung

Stellen Sie sicher, dass die maximale JVM-Heapgröße auf 3,0 GB oder weniger eingestellt ist.

Communications Server zeigt fälschlicherweise CPU-Auslastung an, wenn nur einer der Kerne eines Multikern-Systems verwendet wird (Problem 1344)

Beschreibung

Auf Solaris-Plattformen berechnet Communications Server die CPU-Auslastung basierend auf der Anzahl verfügbarer Prozessoren und der CPU-Auslastung pro Kern. Communications Server berücksichtigt jedoch den statischen Wert der Kernanzahl, nicht die Anzahl der Kerne, die von JVM genutzt werden.

Lösung

Berechnen Sie den Schwellenwert der CPU neu, wenn Sie nicht alle Kerne des Computers verwenden.

Konvergierter Lastenausgleich

Meldungen zu schwerwiegenden Fehlern in Protokollen aufgrund von dynamischer Rekonfiguration von konvergiertem Lastenausgleich nach Bereitstellung der Anwendung (Fehler 1161)

Beschreibung

Wenn Sie die Konfiguration des konvergierten Lastenausgleichs auf einem Ziel ändern und die Anwendungen auf diesem Ziel erneut bereitstellen, zeigen die Instanzprotokolle Meldungen zu schwerwiegenden Fehlern an.

Lösung

Diese Meldungen haben keinen Einfluss auf die Funktion des konvergierten Lastenausgleichs oder der Instanzen. Sie können diese Meldungen ignorieren.

Wenn eine vollständige URI verwendet wird, wird der Parameter BEKey in der Kontakt-Kopfzeile nicht korrekt mit einer Escape-Sequenz versehen (Problem 1466)

Beschreibung

Wenn Sie einen konvergierten Lastenausgleich mit datenorientierten Regeln verwenden, die eine vollständige URI für den Parameter BEKey zurückgeben, wird der Parameter BEKey in der Kontakt-Kopfzeile nicht korrekt mit einer Escape-Sequenz versehen. Bei dem Zeichen ":" funktioniert die Eingabe einer Escape-Sequenz nicht korrekt, wie in RFC 3261 beschrieben.

Lösung

Keine bekannte Lösung.

Installation

Das dateibasierte Installationsprogramm von Communications Server installiert die Beispielanwendung Basic3pcc nicht (Fehler 6894932)

Beschreibung

Das dateibasierte Installationsprogramm von Communications Server installiert die Beispielanwendung Basic3pcc nicht. Diese Anwendung ist im JAR-Installationsprogramm verfügbar.

Lösung

Keine bekannte Lösung.

Communications Server-Installationsprogramm stürzt unter Linux ab (6739013)

Beschreibung

Dieses Problem ist auf Linux-Systemen aufgetreten, auf denen die Umgebungsvariable MALLOC_CHECK_ auf 2 eingestellt ist.

Lösung

Stellen Sie die Umgebungsvariable MALLOC_CHECK_ auf 0 ein. Führen Sie einen der folgenden Befehle aus:

• Für die Bourne-Shell:

  MALLOC_CHECK_=0; export MALLOC_CHECK_

• Für die bash-Shell:

  export MALLOC_CHECK_=0

• Für die csh- und tcsh-Shells:

  setenv MALLOC_CHECK_ 0

Installation mit 64-Bit-JDK schlägt fehl (Problem 6796171)

Beschreibung

Die Installation schlägt auf 64-Bit-Systemen fehl, auf denen ein 64-Bit-JDK installiert ist, da das Installationsprogramm auf das 64-Bit-JDK zugreifen möchte.

Lösung

Wenn Sie Sun GlassFish Communications Server auf einem 64-Bit-System installieren, laden Sie das 32-Bit-JDK herunter, und verwenden Sie es zur Installation von Sun GlassFish Communications Server auf Ihrem 64-Bit-Rechner. Sie müssen dazu den folgenden Befehl verwenden: ./Dateiname_Distribution —javahome Pfad zum Speicherort des 32-Bit-JDKs

Um nach der Installation sicherzustellen, dass Sun GlassFish Communications Server ein 64-Bit-JDK verwendet, bearbeiten Sie den Wert der Variablen AS_JAVA in der Datei asenv.conf, so dass er auf die 64-Bit-JDK-Installation verweist.

Sicherheit

Communications Server löst eine Ausnahme aus, wenn die Eigenschaft "trust-auth-realm-ref" in der Datei sun-sip.xml nicht spezifiziert ist (CR 6786131)

Beschreibung

Communications Server löst den Null-Zeiger-Ausnahmefehler "Bereich ist nicht konfiguriert" aus, wenn P-Asserted-Identity-Authentifizierung in sun-sip.xml konfiguriert ist.

Lösung

Konfigurieren Sie den Bereich mit der Eigenschaft trust-auth-realm-ref in sun-sip.xml.

SIP-Container

SIP-Container kann ABBRECHEN nicht verarbeiten, wenn die Antwort 100 gesendet wurde (Problem 712)

Beschreibung

Der SIP-Container kann eine Anforderung des Typs ABBRECHEN nicht verarbeiten, wenn die Antwort 100 gesendet wurde.

Lösung

Die Anwendung muss eine provisorische Antwort senden (wie z.B. 1xx), sodass die Remote-Seite die Anforderung INVITE ABBRECHEN kann.

SIP-Sitzungen und HTTP-Sitzungen wenden nicht dasselbe Zeitmodell für den Sitzungsablauf an (Problem 1180)

Beschreibung

Das Modell für den Ablauf von SIP-Sitzungen unterscheidet sich von dem für den Ablauf von HTTP-Sitzungen. In HTTP wird die Sitzung außerhalb der Kontrolle der Anwendung jedes Mal automatisch verlängert, wenn eine neue HTTP-Anforderung in dieser HTTP-Sitzung erhalten wird.

Bei SIP-Sitzungen hat die Anwendung Kontrolle über die Dauer der SipApplicationSession (SAS), abhängig von der Zustimmung des SIP-Containers. Anwendungen können mithilfe der Methode setExpires angeben, wann SAS ablaufen soll. setExpires definiert eine Ablaufzeit abhängig von dem Zeitpunkt, zu dem die setExpires-Methode aufgerufen wird. Der Container kann die in setExpires angegebene Dauer ändern, ablehnen oder akzeptieren. Wenn die Sitzung nicht ungültig gemacht wird, wird der Rückruf sessionExpired zu dem in setExpires definierten Zeitpunkt ausgeführt. In diesem Rückruf kann die Anwendung versuchen, die Dauer der SAS durch Aufruf einer neuen setExpires -Methode zu verlängern, was wieder abhängig von der Änderung, Ablehnung oder Annahme durch den Container ist.

Aus diesem Grund stellen konvergierte Anwendungen, die mit derselben Ablaufzeit der SipApplicationSession (SAS) und der HTTP-Sitzung starten, fest, dass die SAS vor der HTTP-Sitzung abläuft, wenn in der HTTP-Sitzung neue Anforderungen eingegangen sind.

Lösung

Aufgrund der unterschiedlichen Handhabung der Ablaufzeit von SIP- und HTTP-Sitzungen sollten Sie mit einer ausreichend langen SAS-Ablaufzeit beginnen, die der voraussichtlichen Gesamtdauer der Anwendungssitzung entspricht (inklusive mehrerer HTTP-Anforderungen). Die SAS-Dauer kann sogar auf unbegrenzt eingestellt werden, insbesondere bei Verwendung von invalidateWhenReady-Semantik. In diesem Fall wird SipApplicationSession ungültig gemacht, wenn die letzte untergeordnete Protokollsitzung ungültig wird. Die anfängliche Ablaufzeit der SAS kann in der Bereitstellungsbeschreibung konfiguriert werden.

Wenn die maximale Gesamtdauer vorab abgeschätzt werden kann, ist kein weiterer Code erforderlich, da es in diesem Fall angebracht ist, sowohl die SIP-Sitzung als auch die HTTP-Sitzung ungültig zu machen, wenn SAS abläuft. Wenn die maximale Dauer nicht vorab abgeschätzt werden kann, kann SipApplicationSession nach Ablauf verlängert werden, wie im Code-Snippet unten gezeigt.

In der Implementierung SipApplicationSessionListener können Sie Folgendes ausführen:

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 
	}

SIP-Sitzung dauert weiter an, nachdem Container-Rückruf zur Sitzung abgelaufen ist (Problem 1265)

Beschreibung

Dieses Problem tritt zeitweise auf. Der SIP-Container antwortet zeitweise mit dem internen Serverfehler 500 anstatt mit der Fehlermeldung 481 "Aufruf/Transaktion existiert nicht", wenn eine Gleichzeitigkeitsbedingung zwischen 200 für BENACHRICHTIGEN, was darauf hinweist, dass die Sitzung entfernt wurde, und dem vom Client gesendeten ABONNIEREN bei Erhalt von BENACHRICHTIGEN besteht.

Lösung

Der Client muss ABONNIEREN aktualisieren, lange bevor das Abonnement abläuft.

Communications Server verhält sich zuerst als UAS, dann als Proxy, und generiert einen Leerlaufprozess (Problem 1432)

Beschreibung

Bei Erhalt einer INVITE-Anforderung verhält sich Communications Server zuerst als UAS, antwortet auf diese Anforderung mit 1XX und übermittelt die INVITE-Anforderung dann an eine andere Instanz, die mit 200 OK antwortet. 1xx erstellt eine interne virtuelle Verzweigung, wohingegen die Meldung 200 eine echte Verzweigung erstellt. Bei Erhalt von 200 OK von B sollte die interne virtuelle Verzweigung abgebrochen werden.

Lösung

Diese Ausnahmeverfolgung betrifft die Funktionalität der virtuellen Proxy-Verzweigung nicht.

Die Methode "getLastAccessedTime" führt zu keinen genauen Ergebnissen (Problem 1351)

Beschreibung

Die getLastAccessedTime-Methode einer SIP-Sitzung stellt keine genauen Ergebnisse bereit.

Lösung

Anwendungen, die lastAccessedTime genau verfolgen müssen, müssen die Informationen selbst in SipApplicationSession speichern.

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-Zielgerät bleibt nach seiner Löschung noch eine Zeit lang aktiv (Problem 1294)

Beschreibung

Nach Löschen eines für TCP- und UDP-Anforderungen konfigurierten SIP-Zielgeräts bleibt das Zielgerät eine Zeit lang aktiv. UDP-Anforderungen, die an das Zielgerät gesendet werden, können eine Antwort vom Zielgerät erhalten.

Lösung

Keine bekannte Lösung. Das SIP-Zielgerät reagiert nach einer bestimmten Zeit nicht mehr auf UDP-Anforderungen. Dieses Problem betrifft TCP-Anforderungen nicht.

Communications Server löst bei Erhalt einer Kontakt-Kopfzeile ohne "<>" eine Ausnahme aus (Problem 1489)

Beschreibung

Communications Server löst bei Erhalt einer Kontakt-Kopfzeile ohne “<>” eine Ausnahme aus. Laut SIP RFC 3261 ist es nicht obligatorisch, dass "<>" in der Adresse enthalten ist. Dies kann zu Interoperabilitätsproblemen mit anderen SIP-kompatiblen Geräten führen.

Lösung

Verwenden Sie "<>" in der Kontakt-Kopfzeile.

Communications Server löst eine Ausnahme bei ungültigem UUID-Wert aus (Problem 1494)

Beschreibung

Communications Server löst eine Ausnahme bei ungültigem UUID-Wert aus, anstatt die Unzulässige Anforderung 400 zurückzugeben. Der Wert UUID befindet sich im sip.instance-Wert der SIP-Kontakt-Kopfzeile.

Lösung

Keine bekannte Lösung.

Windows: Manchmal kann Communications Server UDP-Meldungen nicht empfangen (Keine ID)

Beschreibung

Dieses Problem tritt nur bei Windows zeitweise auf. Communications Server empfängt keine UDP-Meldungen.

Lösung

Stellen Sie folgende JVM-Optionen folgendermaßen ein und starten Sie Communications Server neu.

org.jvnet.glassfish.comms.disableUDPSourcePort=true

SIP-Sitzungsreplikation

Mögliche Sperre, wenn eine konvergierte Anwendung ein SAS-Objekt als Synchronisierungssperre verwendet (Problem 1954)

Beschreibung

Wenn eine konvergierte Anwendung mit HTTP- und SIP-Servlets ein sipApplicationSession -Objekt als Sperre zum Synchronisieren des Zugriffs zwischen SIP- und HTTP-Arbeitsthreads verwendet, wird ein Deadlock beobachtet.

Lösung

Verwenden Sie sipApplicationSession nicht als Synchronisierungssperre. Verwenden Sie stattdessen einen serialisierbaren Objekt-Satz als Attribut in sipApplicationSession als Sperre.