•    setExceptionOnFTEvents
public static void setExceptionOnFTEvents(boolean callExceptionListener)
Sets if ExceptionListener set on the Connection should be called for all the following events: disconnected, each reconnect attempt, and reconnected. Similarly tosetExceptionOnFTSwitch(boolean), if this method is called and if a Connection's ExceptionListener is set, (and the connection has FT urls), then all above events will trigger the call to the ExceptionListener.onException callback with a JMSException which has the vendor error code (JMSException.getErrorCode()) set to the String in the form:

FT-SWITCH: event

Where event is:
•    Disconnected from server url, will attempt to reconnect
•    Reconnecting to next server url, attempt n out of m
•    Reconnected to server url

A JMS application can recognize such calls by analyzing the error code in the passed JMSException and perform necessary actions. Notice that this property replaces the property Tibjms.setExceptionOnFTSwitch(boolean), which means that if both are called, only one "reconnected" event will be passed to the ExceptionListener.onException callback (the one described above). We recommend that if Tibjms.setExceptionOnFTSwitch(boolean) was formerly used, and the user wishes to capture all FT events, this new method be used instead and the ExceptionListener.onException callback modified to handle these new vendor error codes.

Note: When the exception listener is called, the exception listener is not allowed to call any EMS method. To do so in this case risks a deadlock in the client.

===========

Registering an ExceptionListener, which only gets called after one has given up. That listener starts a new thread which keeps trying to reconnect forever until success. You could look at the error code to differentiate the cases:

* "FT-SWITCH: Reconnect[ing/ed ...]" as long as the EMS client keeps trying
* "FT-SWITCH: Disconnected[...]" when the EMS client give up