TIBCO EMS Failover se vuelve a conectar para C # (TIBCO.EMS.dll)

Question

Tenemos una solución TIBCO EMS que utiliza la conmutación por error del servidor incorporada en un entorno de servidor 2-4. Si el TIBCO administra los servicios de conmutación por error de un servidor EMS a otro, se supone que las conexiones se transfieren al nuevo servidor automáticamente en el nivel de servicio EMS. Para nuestras aplicaciones C # que utilizan el servicio EMS, esto no está sucediendo: nuestras conexiones de usuario no se transfieren al nuevo servidor después de la conmutación por error y no estamos seguros de por qué.

Nuestra conexión de la aplicación a EMS solo al inicio, por lo que si los administradores de TIBCO realizan la conmutación por error después de que los usuarios hayan iniciado nuestra aplicación, deben reiniciar la aplicación para volver a conectarse al nuevo servidor (nuestra conexión EMS utiliza una cadena de servidor que incluye los 4 servidores EMS de producción: si el primer intento falla, se mueve al siguiente servidor en la cadena e intenta nuevamente).

Estoy buscando un enfoque automatizado que intente volver a conectarse a EMS periódicamente si detecta que la conexión está inactiva, pero no estoy seguro de cuál es la mejor manera de hacerlo.

¿Alguna idea? Estamos utilizando TIBCO.EMS.dll versión 4.4.2 y .Net 2.x (aplicación SmartClient)

Cualquier ayuda sería apreciada.

Answer 1

Esta publicación debe resumir mis comentarios actuales y explicar mi enfoque con más detalle ...

Los tipos TIBCO 'ConnectionFactory' y 'Connection' son tipos pesados ??y seguros para subprocesos. TIBCO sugiere que mantenga el uso de una ConnectionFactory (por fábrica configurada por el servidor) y una conexión por fábrica.

El servidor también parece ser responsable de la conmutación por error y la reconexión de 'Conexión' en el lugar, así que confirmemos que está haciendo su trabajo y luego nos apoyamos en esa función.

Crear una solución del lado del cliente será un poco más complicado que solucionar un problema de configuración del servidor o del cliente. Todas las sesiones que ha creado a partir de una conexión fallida deben volver a crearse (sin mencionar productores, consumidores y destinos). No hay "reconectar" o "actualizar" métodos en cualquier tipo. Las sesiones tampoco mantienen una referencia a su conexión principal.

¡Tendrá que gestionar una búsqueda de objetos de conexión / sesión y volverse loco reinicializando a todos! o implementar algún tipo de controlador de eventos de falla de sesión que pueda obtener la nueva conexión y volver a conectarlos.

Entonces, por ahora, profundicemos y veamos si el cliente está configurado para recibir notificaciones de conmutación por error (guía del usuario de tib ems, pág. 292). Y asegúrese de que se detecta la excepción generada, contiene la URL de conmutación por error y se está manejando correctamente.

Answer 2

Primero, sí, estoy respondiendo mi propia pregunta. Sin embargo, es importante tener en cuenta que sin ajmastrean no estaría en ninguna parte. muchas gracias!

UNO: ConnectionFactory.SetReconnAttemptCount, SetReconnAttemptDelay, SetReconnAttemptTimeout debe establecerse adecuadamente. Creo que los valores predeterminados se vuelven a intentar demasiado rápido (del orden de 1/2 segundo entre reintentos). Nuestros servidores EMS pueden tardar mucho tiempo en la conmutación por error debido al almacenamiento de la red, etc., por lo que 5 reintentos a intervalos de 1 / 2s no se acercan lo suficiente.

DOS: Creo que es importante habilitar los latidos cliente-servidor y servidor-cliente. No se pudo verificar, pero sin esos en su lugar, el cliente podría no recibir la notificación de que el servidor está fuera de línea o que está cambiando en modo de conmutación por error. Esto, por supuesto, es una configuración del lado del servidor para EMS.

TRES: puede buscar eventos de conmutación por error configurando Tibems.SetExceptionOnFTSwitch (verdadero); y luego cableando un controlador de eventos de excepción. Cuando esté en un entorno de servidor único, verá una "Conexión ha finalizado" mensaje. Sin embargo, si se encuentra en un entorno multiservidor tolerante a fallas, verá esto: "La conexión ha realizado un cambio tolerante a fallas a". No necesita estrictamente esta notificación, pero puede ser útil (especialmente en pruebas).

CUATRO: Aparentemente no está claro en la documentación de EMS, la reconexión de conexión NO funcionará en un entorno de servidor único. Debe estar en un entorno multiservidor y tolerante a fallas. Hay un truco, sin embargo. Puede poner el mismo servidor en la lista de conexiones dos veces; extraño, lo sé, pero funciona y permite que la lógica de reconexión incorporada funcione.

algún código:

private void initEMS()
{
    Tibems.SetExceptionOnFTSwitch(true);
    _ConnectionFactory = new TIBCO.EMS.TopicConnectionFactory(<server>);
    _ConnectionFactory.SetReconnAttemptCount(30);       // 30retries
    _ConnectionFactory.SetReconnAttemptDelay(120000);   // 2minutes
    _ConnectionFactory.SetReconnAttemptTimeout(2000);   // 2seconds
_Connection = _ConnectionFactory.CreateTopicConnectionM(<username>, <password>);
    _Connection.ExceptionHandler += new EMSExceptionHandler(_Connection_ExceptionHandler);
}
private void _Connection_ExceptionHandler(object sender, EMSExceptionEventArgs args)
{
    EMSException e = args.Exception;
    // args.Exception = "Connection has been terminated" -- single server failure
    // args.Exception = "Connection has performed fault-tolerant switch to <server url>" -- fault-tolerant multi-server
    MessageBox.Show(e.ToString());
}

Answer 3

Las aplicaciones del cliente pueden recibir notificaciones de una conmutación por error configurando la propiedad del sistema tibco.tibjms.ft.switch.exception

¿Quizás la biblioteca necesita eso para funcionar?