Capítulo 3 Limitaciones y problemas conocidos de Sun GlassFish Communications Server

En este capítulo se describen los problemas conocidos y las correspondientes soluciones del software Communications Server. Si no se especifica una plataforma concreta para un problema, significa que éste se aplica a todas las plataformas. Esta información se ha dividido como sigue:

• Administración de Communications Server

• Equilibrador de carga convergente

• Instalación

• Seguridad

• Contenedor SIP

• Replicación de sesiones SIP

Administración de Communications Server

Communications Server no detecta los conflictos con el puerto heartbeat de un clúster (número de problema 1967)

Descripción

Cuando se crea un clúster, Communications Server asigna aleatoriamente un puerto heartbeat entre 1026 y 45556. Para un clúster predeterminado, creado por una instalación de Communications Server, un número aleatorio entre 0 y 45556. El proceso de creación del clúster no detecta con precisión si el puerto heartbeat ya lo está usando otro servicio.

Solución

Si la configuración automatizada de creación de clústeres selecciona un puerto heartbeat que se encuentra en conflicto con otro servicio que ya está utilizando dicho puerto, actualice el puerto heartbeat del clúster a un puerto que no esté usando el sistema.

Para cambiar el puerto heartbeat de un clúster, utilice el siguiente comando asadmin :

asadmin set cluster-name.heartbeat-port= newportnumber

La creación del dominio se detiene en un servidor NFS que se ejecute en Linux de 64 bits (número de problema 1961)

Descripción

El comando asadmin create-domain puede fallar al intentar crear un dominio en un sistema de archivos montados en NFS, con el servidor NFS ejecutándose en Linux de 64 bits.

Solución

No hay una solución conocida.

Alta utilización de la CPU cuando hay poco tráfico o ni siquiera hay (número de problema 1966)

Descripción

En algunas ocasiones, las instancias de Communications Server presentan un alto nivel de utilización de la CPU aunque haya poco tráfico o ni siguiera haya, si está habilitada la protección contra sobrecarga de la CPU. Este problema se produce debido al error de JDK 6693490. Este error se solucionará en JDK 6 Update 18.

Solución

Utilice JDK 6 Update 18 con Communications Server.

Las instancias de Communications Server se inician incluso aunque no se haya conectado a los puertos SIP ni SIPS (número de problema 998)

Descripción

Las instancias de Communications Server se inician aunque no puedan conectarse a ningún puerto SIP ni SIPS.

Solución

Compruebe que los puertos estén libres antes de iniciar las instancias del servidor. Compruebe los archivos de registro (server.log) para garantizar que no se ha producido ningún error ni excepción en el contenedor SIP durante el inicio.

Communications Server no utiliza el JDK especificado mediante la opción ––javahome (número de problema 789)

Descripción

Puede utilizar un JDK preinstalado en lugar de la versión predeterminada para la instalación usando la opción ––javahome. De forma predeterminada, Communications Server utiliza la versión de JDK de as-install/jdk.

Solución

La variable AS_JAVA del archivo asenv.conf siempre señala a as-install/jdk. Si desea utilizar una versión de JDK diferente, actualice el archivo asenv.conf manualmente y cambie el valor de AS_JAVA.

Al utilizar la pila Java de 3,5 GB, las instancias se reinician cuando el tráfico está activo (número de problema 1169)

Descripción

Cuando el tamaño de la pila de JVM está establecido en 3,5 GB, las instancias de Communications Server fallan y se reinician cuando reciben tráfico.

Solución

Compruebe que el tamaño máximo de la pila de JVM esté establecido en 3,0 GB o menos.

Communications Server informa de informa incorrecta sobre el uso de la CPU cuando se utiliza sólo uno de los núcleos de un sistema de varios núcleos (número de problema 1344)

Descripción

En las plataformas Solaris, Communications Server calcula el uso de la CPU según el número de procesadores disponibles y el uso de la CPU por núcleo. Sin embargo, Communications Server tiene en cuenta el valor estático del número de núcleos, en lugar del número de núcleos que utiliza el JVM.

Solución

Volver a calcular los valores de umbral de CPU si no se están utilizando todos los núcleos del equipo.

Equilibrador de carga convergente

Aparecen mensajes GRAVES en los registros debido a la reconfiguración dinámica del equilibrador de carga convergente tras la implementación de la aplicación (número de problema 1161)

Descripción

Si modifica la configuración del equilibrador de carga convergente en un destino y vuelve a implementar las aplicaciones en dicho destino, aparecerán mensajes GRAVES en los registros de la instancia.

Solución

Estos mensajes no afectan al funcionamiento del equilibrador de carga convergente ni a las instancias. Haga caso omiso de estos mensajes.

Cuando se haya utilizado el URI completo, el parámetro BEKey de la cabecera de contacto no se omite correctamente (número de problema 1466)

Descripción

Cuando se utiliza un equilibrador de carga convergente con un archivo de reglas centradas en datos que devuelve un URI completo para el parámetro BEKey, el parámetro BEKey de la cabecera de contacto no se omite correctamente. El carácter ":" no se omite correctamente, tal y como se especifica en RFC 3261.

Solución

No hay una solución conocida.

Instalación

Al ejecutar los archivos de instalación de Communications Server no instala la aplicación de muestra Basic3pcc (número de error 6894932)

Descripción

Al ejecutar los archivos de instalación de Communications Server no se instala la aplicación de muestra Basic3pcc. El programa de instalación JAR incluye esta aplicación.

Solución

No hay una solución conocida.

El programa de instalación de Communications Server se bloquea en Linux (6739013)

Descripción

Este problema se ha observado en sistemas con Linux y una variable de entorno, MALLOC_CHECK_, establecida en 2.

Solución

Establezca la variable de entorno, MALLOC_CHECK_,en 0. Ejecute uno de los siguientes comandos:

• Para el intérprete de comandos Bourne:

  MALLOC_CHECK_=0; export MALLOC_CHECK_

• Para el intérprete de comandos bash:

  export MALLOC_CHECK_=0

• Para el intérprete de comandos csh, tcsh:

  setenv MALLOC_CHECK_ 0

Error en la instalación con JDK de 64 bits (6796171)

Descripción

La instalación falla en sistemas de 64 bits que tengan JDK de 64 bits porque el programa de instalación intenta utilizar el JDK de 64 bits.

Solución

Si está instalando Sun GlassFish Communications Server en un sistema de 64 bits, descargue el JDK de 32 bits y utilícelo para instalar Sun GlassFish Communications Server en el equipo de 64 bits. Debe utilizar el siguiente comando: ./distribution_filename —javahome ruta a la ubicación del JDK de 32 bits

Después de la instalación, para asegurarse de que Sun GlassFish Communications Server utiliza un JDK de 64 bits, modifique el valor de la variable AS_JAVA en el archivo asenv.conf para que señale a la instalación JDK de 64 bits.

Seguridad

Communications Server genera una excepción si la propiedad trust-auth-realm-ref no está especificada en el archivo sun-sip.xml (número de error 6786131)

Descripción

Communications Server genera una excepción de puntero nulo si el dominio no está configurado cuando la autenticación P-Asserted-Identity está configurada en el archivo sun-sip.xml.

Solución

Configure el dominio mediante la propiedad trust-auth-realm-ref del archivo sun-sip.xml.

Contenedor SIP

El contenedor SIP no puede procesar solicitudes de CANCELACIÓN si ha enviado una respuesta 100 (número de problema 712)

Descripción

El contenedor SIP no puede procesar solicitudes de CANCELACIÓN si se ha enviado una respuesta 100.

Solución

La aplicación debe enviar una respuesta provisional (como 1xx), de modo que la instancia remota sea capaz de CANCELAR la solicitud de INVITACIÓN.

Las sesiones SIP y HTTP no aplican el mismo modelo de tiempo de finalización de sesión (número de problema 1180)

Descripción

El modelo de finalización de sesión de las sesiones SIP es distinto a la lógica de tiempo de finalización del protocolo HTTP. En HTTP, la duración de la sesión se amplía de forma automática, fuera del control de la aplicación, siempre que la sesión HTTP recibe una solicitud HTTP.

En cambio, en las sesiones SIP, la aplicación se encuentra bajo el control de la SipApplicationSession (SAS) que, a su vez, debe aprobar el contendor SIP. Las aplicaciones pueden usar el método setExpires para indicar cuándo debe finalizar la SAS. setExpires define el tiempo de finalización relativo al momento en el que se invoca el método setExpires. El contenedor puede modificar, rechazar o aceptar la duración indicada en setExpires . Si la sesión se no se ha invalidado, la devolución de llamada sessionExpired se genera en el momento definido por setExpires. En dicha devolución de llamada, la aplicación puede intentar ampliar la duración de la SAS invocando un nuevo método setExpires, una vez más sujeto a la modificación, el rechazo o la aceptación por parte del contenedor.

Por este motivo, en las aplicaciones convergentes que se inicien con el mismo tiempo de finalización en la SipApplicationSession (SAS) y en la sesión HTTP, el tiempo de SAS se agotará antes que el de la sesión HTTP si se han recibido solicitudes nuevas en la sesión HTTP.

Solución

La mejor forma de afrontar la divergencia entre la administración del tiempo de finalización de la sesión SIP y la sesión HTTP es comenzar con un tiempo de finalización de la SAS de una duración conveniente, que debe corresponderse con el periodo de tiempo total que se prevé que durará la sesión de aplicaciones (incluidas varias solicitudes HTTP). El ciclo de duración de la SAS se puede definir incluso como infinito, en concreto si se utiliza la semántica invalidateWhenReady, en cuyo caso, SipApplicationSession se invalida cuando la última sesión secundaria de protocolo queda invalidada. El tiempo inicial de finalización de la SAS se puede configurar en el descriptor de implementación.

Si la duración total máxima puede estimarse por adelantado, no se necesita ningún otro código, ya que el código actual es apropiado para invalidar la sesión SIP y la sesión HTTP cuando la SAS caduque. Si la duración máxima no se puede estimar por adelantado, la duración de la SipApplicationSession puede ampliarse cuando ésta haya caducado, tal y como se muestra en el fragmento de código siguiente.

En la implementación de SipApplicationSessionListener, puede hacer algo así:

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 sesión SIP no finaliza tras la devolución de llamada de contenedor sessionExpired (problema 1265)

Descripción

Se trata de un problema ocasional. El contenedor SIP responde de forma intermitente con un mensaje de error de servidor 500, en lugar de con un mensaje 481 en el que se indica que la llamada o transacción no existe cuando hay una condición de competencia entre el mensaje 200 para la solicitud de NOTIFICACIÓN, lo cual indica que la sesión se ha eliminado, y la solicitud de SUSCRIPCIÓN enviada por el cliente al recibir la NOTIFICACIÓN.

Solución

El cliente debe actualizar la solicitud de SUSCRIPCIÓN mucho antes de que la suscripción caduque.

Communications Server primero actúa como UAS, a continuación como proxy y, finalmente, genera una instrucción NOP (problema 1432)

Descripción

Cuando recibe una solicitud de INVITACIÓN, Communications Server primero actúa como UAS, responde a la solicitud con 1XX y, a continuación, envía mediante el servidor proxy la solicitud de INVITACIÓN a otra instancia, que responde con el mensaje 200 ACEPTADO. 1xx crea una bifurcación virtual interna, mientras que el mensaje 200 crea una bifurcación real. Cuando se recibe el mensaje 200 ACEPTADO de B, se debe cancelar la bifurcación virtual interna.

Solución

El seguimiento de esta excepción no afecta a las funciones de la bifurcación virtual del proxy.

El método getLastAccessedTime no proporciona resultados precisos (problema 1351)

Descripción

El método getLastAccessedTime de una sesión SIP no proporciona resultados precisos.

Solución

Las aplicaciones que deben mantener un seguimiento de lastAccessedTime tendrán que almacenar la información automáticamente en la 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());
}

La escucha SIP permanece activa durante un cierto tiempo después de eliminarla (problema 1294)

Descripción

Después de eliminar una escucha SIP que está configurada para solicitudes TCP y UDP, la escucha permanece activa durante un cierto tiempo. Las solicitudes UDP que se envían a la escucha podrían recibir una respuesta de la escucha.

Solución

No hay una solución conocida. La escucha SIP deja de recibir solicitudes UDP después de un cierto tiempo. Este problema no afecta a las solicitudes TCP.

Communications Server genera una excepción cuando recibe una cabecera de contacto sin "<>" (problema 1489)

Descripción

Communications Server genera una excepción cuando recibe una cabecera de contacto sin "<>". Según SIP RFC 3261, no es obligatorio que la dirección contenga "<>". Esto puede provocar problemas de interoperabilidad con otros dispositivos compatibles con SIP.

Solución

Utilice "<>" en la cabecera de contacto.

Communications Server genera una excepción en un valor UUID no válido (problema 1494)

Descripción

Communications Server genera excepciones en un valor UUID no válido, en lugar de devolver el mensaje 400 de solicitud errónea. El valor UUID se encuentra en el valor sip.instance de la cabecera de contacto SIP.

Solución

No hay una solución conocida.

Windows: a veces, Communications Server no recibe los mensajes UDP (sin Id.)

Descripción

Este problema aparece de forma intermitente únicamente en Windows. Communications Server no recibe los mensajes UDP.

Solución

Defina la siguiente opción de JVM tal y como se describe a continuación y reinicie Communications Server.

org.jvnet.glassfish.comms.disableUDPSourcePort=true

Replicación de sesiones SIP

Si una aplicación convergente utiliza un objeto SAS como bloqueo de sincronización, se puede producir un interbloqueo (número de problema 1954)

Descripción

Si una aplicación convergente que dispone de servlets HTTP y SIP utiliza un objeto sipApplicationSession como bloqueo para sincronizar el acceso entre subprocesos de trabajo SIP y HTTP, se produce un interbloqueo.

Solución

No utilice sipApplicationSession como bloqueo de sincronización. En su lugar, utilice como bloqueo un objeto serializable definido como atributo en sipApplicationSession .