Conmutación por error de TIBCO EMS se vuelve a conectar para C#(TIBCO.EMS.dll)

tibco-ems

Question

Tenemos una solución TIBCO EMS que utiliza failover de servidor incorporado en un entorno de servidor 2-4. Si los administradores de TIBCO conmutan los servicios de un servidor EMS a otro, se supone que las conexiones se transfieren automáticamente al nuevo servidor en el nivel de servicio EMS. Para nuestras aplicaciones C # que usan 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 aplicaciones al EMS solo al inicio, de modo que si los administradores de TIBCO conmutan por error después de que los usuarios hayan iniciado nuestra aplicación, los usuarios deben reiniciar la aplicación para volver a conectarse al nuevo servidor (nuestra conexión EMS usa 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 y lo intenta de nuevo).

Estoy buscando un enfoque automático que intente reconectarse al EMS periódicamente si detecta que la conexión está muerta, pero no estoy seguro de cuál es la mejor manera de hacerlo.

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

Cualquier ayuda sería apreciada.

Answer 1

Las aplicaciones 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?

Answer 2

Primero, sí, estoy respondiendo mi propia pregunta. Es importante señalar, sin embargo, que sin ajmastrean, no estaría en ninguna parte. ¡Muchas gracias!

ONE: ConnectionFactory.SetReconnAttemptCount, SetReconnAttemptDelay, SetReconnAttemptTimeout se debe configurar de manera adecuada. Creo que los valores predeterminados vuelven a intentar demasiado rápido (en el orden de 1/2 segundo entre reintentos). Nuestros servidores EMS pueden demorar mucho tiempo en conmutación por error debido al almacenamiento en la red, etc., por lo que 5 intentos a intervalos de 1/2 no son lo suficientemente largos.

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

TRES: puede ver el evento de conmutación por error estableciendo Tibems.SetExceptionOnFTSwitch (true); y luego conectando un controlador de evento de excepción. Cuando se encuentre en un entorno de servidor único, verá el mensaje "La conexión ha finalizado". Sin embargo, si se encuentra en un entorno multiservidor tolerante a fallas, verá esto: "La conexión ha realizado el cambio tolerante a fallas a". No necesita estrictamente esta notificación, pero puede ser útil (especialmente en las 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 tolerante a fallas de varios servidores. 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

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 recuperación de fallas y la reconexión in situ de ''Conexión'', así que confirmemos que está haciendo su trabajo y luego apóyate en esa característica.

Crear una solución del lado del cliente va a ser un poco más complicado que solucionar un problema de instalación del servidor o del cliente. Deben recrearse todas las sesiones que haya creado a partir de una conexión fallida (sin mencionar productores, consumidores y destinos). No hay métodos de "reconexión" o "actualización" en ningún tipo. Las sesiones tampoco mantienen una referencia a su conexión principal.

¡Tendrás que gestionar una búsqueda de objetos de conexión / sesión y volverse loco al reiniciar 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.

Por lo tanto, por ahora, investiguemos y veamos si el cliente está configurado para recibir notificaciones de failover (guía de usuarios de tib ems, página 292). Y asegúrese de que la excepción planteada sea capturada, contenga la URL de conmutación por error y se maneje correctamente.