Chapitre 3 Problèmes connus et restrictions de Sun GlassFish Communications Server

Ce chapitre décrit les problèmes connus relatifs au logiciel Communications Server et les solutions associées. Si aucune plate-forme particulière n'est spécifiée, le problème s'applique à toutes les plates-formes. Voici les sujets abordés :

• Administration de Communications Server

• Équilibreur de charge convergent

• Installation

• Sécurité

• Conteneur SIP

• Réplication de session SIP

Administration de Communications Server

Communications Server ne détecte pas de conflit avec le port de pulsation d'un cluster (numéro de problème 1967).

Description

Lorsqu'un cluster est créé, Communications Server assigne de manière aléatoire un port de pulsation compris entre 1026 à 45556. Pour le cluster par défaut, à savoir le cluster créé par une installation de Communications Server, un nombre aléatoire compris entre 0 et 45556 est sélectionné. Le processus de création d'un cluster ne détermine pas avec précision si le port de pulsation est déjà utilisé par un autre service.

Solution

Si la configuration automatique de la création d'un cluster sélectionne un port de pulsation qui est en conflit avec un autre service qui utilise déjà ce port, mettez à jour le port de pulsation du cluster vers un port non utilisé par le système.

Pour modifier le port de pulsation d'un cluster, utilisez la commande asadmin suivante :

asadmin set nom-cluster.heartbeat-port= nouveau-numéro-port

La création de domaine s'arrête sur un serveur NFS exécutant Linux 64 bits (numéro de problème 1961).

Description

La commande asadmin create-domain risque d'échouer lors de la tentative de création d'un domaine sur un système de fichiers NFS (Network File System) avec le serveur NFS sous Linux 64 bits.

Solution

Aucune solution connue.

Utilisation élevée de la CPU lorsqu'il y a peu ou pas de trafic (Problème 1966)

Description

Les instances de Communications Server affichent parfois une utilisation importante de la CPU même avec peu ou pas de trafic lorsque la protection de la CPU contre les surcharges est activé. Ce problème découle du bogue JDK 6693490. Ce bogue est résolu dans JDK 6 Update 18.

Solution

Utilisez JDK 6 Update 18 avec Communications Server.

Les instances de Communications Server démarrent même si les ports SIP/SIPS ne sont pas liés (Problème 998)

Description

Les instances de Communications Server démarrent même si elles ne peuvent pas être liées à un port SIPS ou SIP.

Solution

Assurez-vous que les ports sont libres avant de démarrer les instances de serveur. Consultez les fichiers journaux (server.log) pour vous assurer qu'il n'y a pas eu d'erreur ou d'exception au niveau du conteneur SIP au démarrage.

Communications Server n'utilise pas le JDK spécifié par l'option ––javahome (Problème 789)

Description

Vous pouvez utiliser un JDK préinstallé au lieu de la version par défaut pour l'installation via l'option ––javahome. Par défaut, Communications Server utilise la version JDK disponible sous as-install/jdk.

Solution

La variable AS_JAVA du fichier asenv.conf pointe toujours vers as-install/jdk. Si vous souhaitez utiliser une autre version de JDK, mettez à jour le fichier asenv.conf manuellement et modifiez la valeur de AS_JAVA.

L'utilisation du tas Java 3,5 Go entraîne le redémarrage des instances alors que du trafic est en cours (Problème 1169)

Description

Lorsque la taille du tas JVM est définie sur 3,5 Go, les instances de Communications Server ne fonctionnent pas et redémarrent lorsqu'elles reçoivent du trafic.

Solution

Assurez-vous que la taille maximale du tas JVM est définie sur 3,0 Go ou moins.

Communications Server indique l'utilisation de la CPU de manière incorrecte lorsque vous utilisez uniquement l'un des cœurs du système multi-cœurs (Problème 1344)

Description

Sur les plates-formes Solaris, Communications Server calcule l'utilisation de la CPU en fonction du nombre de processeurs disponibles et de l'utilisation de la CPU par cœur. Cependant, Communications Server prend en compte la valeur statique du nombre de cœurs et non pas le nombre de cœurs utilisés par le tas JVM.

Solution

Recalculez les valeurs de seuil de la CPU si vous n'utilisez pas tous les cœurs de la machine.

Équilibreur de charge convergent

Messages GRAVES dans les journaux en raison de la reconfiguration dynamique de l'équilibreur de charge convergent après le déploiement de l'application (Problème 1161)

Description

Si vous modifiez la configuration de l'équilibreur de charge convergent sur une cible et redéployez les applications sur cette cible, les journaux d'instance vous afficheront des messages GRAVES.

Solution

Ces messages n'ont pas d'incidence sur le fonctionnement de l'équilibreur de charge convergent ou sur les instances. Ne tenez pas compte de ces messages.

Lorsque l'URI entier est utilisé, le paramètre BEKey de l'en-tête Contact n'est pas échappé correctement (Problème 1466)

Description

Lorsque vous utilisez un équilibreur de charge convergent avec une règle centrée de données qui renvoie un URI complet pour le paramètre BEKey, le paramètre BEKey dans l'en-tête Contact n'est pas échappé correctement. Le caractère « : » n'est pas correctement échappé comme indiqué dans la spécification RFC 3261.

Solution

Aucune solution connue.

Installation

Le programme d'installation basé sur des fichiers de Communications Server n'installe pas l'exemple d'application Basic3pcc (Bogue 6894932)

Description

Le programme d'installation basé sur des fichiers de Communications Server n'installe pas l'exemple d'application Basic3pcc. Cette application est disponible avec le programme d'installation JAR.

Solution

Aucune solution connue.

Le programme d'installation de Communications Server provoque une panne système sous Linux (6739013)

Description

Ce problème a été observé sur des systèmes exécutés sous Linux avec la variable d'environnement, MALLOC_CHECK_, défini à 2.

Solution

Définissez la variable d'environnement, MALLOC_CHECK_ à 0. Exécutez l'une des commandes suivantes :

• Pour le bourne shell :

  MALLOC_CHECK_=0; export MALLOC_CHECK_

• Pour le bash shell:

  export MALLOC_CHECK_=0

• Pour le csh, tcsh shell :

  setenv MALLOC_CHECK_ 0

Échec de l'installation avec le JDK 64 bits (6796171)

Description

Échec de l'installation sur les systèmes 64 bits qui disposent du JDK 64 bits, car le programme d'installation tente d'utiliser le JDK 64 bits.

Solution

Si vous installez Sun GlassFish Communications Server sur un système 64 bits, téléchargez le JDK 32 bits et utilisez-le pour installer Sun GlassFish Communications Server sur votre machine 64 bits. Vous devez utiliser la commande suivante : . /nom-fichier-distribution —javahome chemin d'accès à l'emplacement du JDK 32 bits

Après l'installation, pour vous assurer que Sun GlassFish Communications Server utilise un JDK 64 bits, modifiez la valeur de la variable AS_JAVA dans le fichier asenv.conf pour qu'elle pointe vers l'installation du JDK 64 bits.

Sécurité

Communications Server renvoie une exception lorsque la propriété trust-auth-realm-ref n'est pas spécifiée dans sun-sip.xml (CR 6786131)

Description

Communications Server renvoie une exception Pointeur nul, domaine non configuré lorsque l'authentification P-Asserted-Identity est configurée dans sun-sip.xml.

Solution

Configurez le domaine à l'aide de la propriété trust-auth-realm-ref dans sun-sip.xml.

Conteneur SIP

Le conteneur SIP ne parvient pas à traiter une requête d'annulation lorsqu'il a renvoyé une réponse 100 (Problème 712)

Description

Le conteneur SIP ne peut pas traiter une requête d'annulation lorsqu'une réponse 100 a été envoyée.

Solution

L'application doit envoyer une réponse provisoire (telle que 1xx), de manière à ce que la partie distante puisse annuler la requête d'invitation.

Les sessions SIP et les sessions HTTP n'appliquent pas le même modèle de délai d'expiration de session (Problème 1180)

Description

Le modèle d'expiration de session des sessions SIP est différent de la logique de délai d'expiration HTTP. Dans le modèle HTTP, la session est automatiquement étendue, hors contrôle de l'application, chaque fois qu'une nouvelle requête HTTP est reçue dans cette session HTTP.

Avec les sessions SIP, l'application contrôle la durée de la session SipApplicationSession (SAS), sujette à l'approbation du conteneur SIP. Les applications peuvent utiliser la méthode setExpires pour indiquer que cette SAS devrait expirer. setExpires définit un délai d'expiration par rapport au moment où la méthode setExpires est appelée. Le conteneur peut modifier, rejeter ou accepter la durée indiquée dans setExpires. Si la session n'est pas invalidée, alors le rappel sessionExpired est réalisé au moment défini par setExpires. Dans ce rappel, l'application peut tenter d'étendre la durée de la SAS en appelant un nouveau setExpires, également sujet à modification, rejet ou acceptation par le conteneur.

Pour cette raison, les applications convergentes qui commencent avec la même heure d'expiration que la session SipApplicationSession (SAS) et la session HTTP noteront que la session SAS expire avant la session HTTP si de nouvelles requêtes ont été reçues sur la session HTTP.

Solution

La meilleure manière de gérer les différents délais d'expiration des sessions SIP et HTTP est de commencer avec un délai d'expiration SAS suffisamment long, qui représente la durée totale prévue de la session d'application (avec plusieurs requêtes HTTP). La durée de vie d'une session SAS pourrait même être réglée sur l'infini, en particulier si la sémantique invalidateWhenReady est utilisée, auquel cas la session SipApplicationSession est invalidée lorsque la dernière session enfant du protocole est invalidée. Le premier délai d'expiration pour le SAS peut être configuré dans le descripteur de déploiement.

Si la durée totale maximale peut être estimée à l'avance, aucun autre code est nécessaire, puisqu'il convient donc d'invalider la session SIP et la session HTTP lorsque le SAS expire. Si la durée maximale ne peut être estimée à l'avance, la session SipApplicationSession peut être étendue lorsqu'elle arrive à expiration, comme illustré dans le fragment de code ci-dessous.

Dans l'implémentation SipApplicationSessionListener, vous pouvez effectuer une action, comme suit :

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 
	}

La session SIP se poursuit après le rappel du conteneur pour sessionExpired (Problème 1265)

Description

Il s'agit d'un problème intermittent. Le conteneur SIP répond par intermittence avec un message d'erreur interne 500 Serveur au lieu d'une erreur 481 Appel/Transaction inexistant lorsqu'il y a une condition de compétitivité entre l'erreur 200 de notification indiquant que la session a été supprimée et la requête d'inscription envoyée par le client lorsqu'il reçoit cette notification.

Solution

Le client doit actualiser la requête d'inscription avant que l'abonnement expire.

Communications Server agit d'abord comme un UAS, puis en tant que proxy, puis génère un NOP (Problème 1432)

Description

Lorsqu'il reçoit une requête d'invitation, Communications Server agit d'abord comme un UAS, répond à cette requête avec 1XX, puis transmet cette demande d'invitation à une autre instance, qui envoie une réponse 200 OK. Le 1xx crée une branche virtuelle interne tandis que le message 200 crée une branche réelle. Une fois le message 200 OK de B reçu, la branche virtuelle interne doit être annulée.

Solution

Cette trace d'exception n'affecte pas la fonctionnalité de la branche de proxy virtuelle.

La méthode getLastAccessedTime ne permet pas de fournir des résultats précis (Problème 1351)

Description

La méthode getLastAccessedTime d'une session SIP ne permet pas de fournir des résultats précis.

Solution

Les applications nécessitant de conserver une trace précise de lastAccessedTime doivent être stockées dans 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());
}

Le listener SIP reste actif un certain temps après sa suppression (Problème 1294)

Description

Après la suppression d'un listener SIP configuré pour des requêtes TCP et UDP, il reste actif pendant quelques instants. Les requêtes UDP envoyées au listener peuvent recevoir une réponse du listener.

Solution

Aucune solution connue. Le listener SIP arrête l'écoute des requêtes UDP après un certain temps. Ce problème n'a aucun impact sur les requêtes TCP.

Communications Server génère une exception lors de la réception d'un en-tête Contact sans « <> » (Problème 1489)

Description

Communications Server génère une exception lors de la réception d'un en-tête Contact sans « <> ». Conformément à la spécification SIP RFC 3261, il n'est pas obligatoire d'indiquer « <> » dans l'adresse. Cela peut entraîner des problèmes d'interopérabilité avec d'autres périphériques non compatibles SIP.

Solution

Utilisez « <> » dans l'en-tête Contact.

Communications Server génère une exception sur une valeur UUID incorrecte (Problème 1494)

Description

Communications Server génère une exception sur une valeur UUID incorrecte au lieu de renvoyer une erreur 400, Requête erronée. La valeur UUID réside dans la valeur sip.instance de l'en-tête du contact SIP.

Solution

Aucune solution connue.

Windows : parfois Communications Server ne reçoit pas les messages UDP (pas d'ID)

Description

Ce problème n'est rencontré que par intermittence et sous Windows. Communications Server ne reçoit pas les messages UDP.

Solution

Définissez l'option JVM suivante comme suit et redémarrez Communications Server.

org.jvnet.glassfish.comms.disableUDPSourcePort=true

Réplication de session SIP

Interblocage possible si une application convergente utilise un objet SAS comme verrou de synchronisation (Problème 1954)

Description

Si une application convergente dotée de servlets HTTP et SIP utilise un objet sipApplicationSession comme verrou pour synchroniser l'accès entre les flux de travail SIP et HTTP, un interblocage est observé.

Solution

N'utilisez pas sipApplicationSession comme verrou de synchronisation. Utilisez plutôt un objet sérialisable défini comme un attribut dans sipApplicationSession comme verrou.