¿El servidor TIBCO EMS gestiona la reconexión? o el cliente?

Question

La guía de referencia TIBCO EMS .NET dice (pág. 134)

  

Para habilitar el comportamiento de reconexión y la tolerancia a errores, el parámetro serverURL debe ser una lista separada por comas de dos o más URL. En una situación con un solo servidor, puede suministrar dos copias de la URL de ese servidor para habilitar la reconexión del cliente (por ejemplo, tcp: // localhost: 7222, tcp: // localhost: 7222).

La guía del usuario de TIBCO EMS (pág. 292) habla sobre escenarios de conmutación por error, notificación de clientes y transferencia automática de clientes al servidor de respaldo, pero nada específicamente " reconectarse " relacionado.

En una "reconexión" escenario, ¿el servidor maneja todo? o ¿el cliente tiene que hacer algo con sus instancias TIBCO.EMS.Connection?

Answer 1

Parece que, a partir de nuestras pruebas, hay configuraciones tanto en el servidor como en el cliente que habilitan esta función. En el lado del cliente, SetReconnAttemptCount, Delay, Timeout rigen los intentos que el cliente intenta volver a conectar una vez que tiene conocimiento de una conmutación por error del servidor / conmutación por error de conexión.

En nuestras pruebas, utilizamos un entorno de servidor único, enumeramos el servidor dos veces en la cadena de conexión (utilizando el truco que describió anteriormente) y cuando ese servidor se desconectó, recibimos una notificación del cliente sobre el efecto del proceso de conmutación por error ( activamos Tibems.SetExceptionOnFTSwitch (verdadero)) y cuando el servidor se volvió a conectar, nuestro cliente se volvió a conectar sin perder el ritmo. No necesitábamos codificar nada, la lógica de reconexión interna hizo su magia.

En el lado del servidor, la tolerancia a fallas debe estar habilitada y creo que los latidos del servidor-cliente y cliente-servidor deben estar habilitados (aunque esto aún no se ha verificado).

Espero que esto ayude.