위와 같은 구성에서 Active 서버들 중 하나에 장애가 발생하면 우선 아무런 서비스를 하고 있지 않은 Standby 서버들 중 하나가 그 역할을 이어받아서 서비스한다. 서비스를 수행하고 있는 Active 서버들과 Standby 서버들 중 하나에 추가적으로 장애가 발생하면 마찬가지로 서비스를 하고 있지 않은 Standby 서버들 중 하나가 이어받게 되며, 더 이상 서비스를 수행하고 있지 않은 서버가 없다면 서비스를 수행하고 있는 Active 서버들 중의 하나가 이어받아서 한 서버가 두 개 이상의 서버 역할을 하게 된다. 이는 해당 구성에서 마지막 하나의 서버만 남을 때까지 계속되며 마지막 남은 서버에도 장애가 발생하면 JEUS MQ 클러스터링 서비스는 더 이상 동작하지 않는다.

WebAdmin에서 [Servers] > [서버명] > [Engine] > [Jms Engine] > [Basic] 메뉴를 선택하면, Jms Failover 설정 화면이 나타난다.

다음은 Active 서버와 Standby 서버의 장애 극복 설정을 하는 예제이다.

기본적으로는 재연결을 하지 않기 때문에 화면에서 'Reconnect Enabled' 항목을 체크해서 true로 설정한다. 'Reconnect Enabled' 항목이 활성화되면 JEUS MQ 클라이언트는 Active 서버와 Standby 서버에 반복해서 재연결을 시도한다.

JEUS MQ 클러스터 내의 Active 서버와 Standby 서버들은 동일한 이름의 Connection Factory를 가지고 있기 때문에 한 번 JNDI Lookup을 통해서 얻은 Connection Factory는 서버나 네트워크의 장애가 발생한 경우에 다시 Lookup할 필요없이 재사용할 수 있다.

Connection Factory와 마찬가지로 JEUS MQ 클러스터 내의 Active 서버와 Standby 서버들은 동일한 이름의 Destination을 가지고 있다. 따라서 한 번 JNDI Lookup을 통해서 얻은 Destination은 서버나 네트워크에 장애가 발생해도 다시 JNDI를 Lookup할 필요없이 재사용할 수 있다.

장애 발생 이전에 Destination에 저장되었던 메시지들은 서버 장애가 발생한 경우 모두 자동 복구되므로 클라이언트는 해당 Destination을 통해서 메시징 작업을 계속할 수 있다.

서버뿐만 아니라 각 커넥션별로 다른 설정을 하는 경우 JEUS MQ Client API인 "jeus.jms.client.facility.connection.JeusConnection" 클래스를 이용하여 설정을 변경할 수 있다.

. . .
import jeus.jms.client.facility.connection.JeusConnection;
. . .
Context ctx = new InitialContext();
ConnectionFactory factory = ctx.lookup("connection-factory");
JeusConnection connection = (JeusConnection)factory.createConnection("jeus", "jeus");
connection.setRequestBlockingTime(300000); // 5분
. . .

RequestBlockingTime은 세션 트랜잭션이나 XA의 경우에 트랜잭션 타임아웃의 기본값으로도 사용된다.

커넥션 복구가 설정되지 않은 JEUS MQ의 커넥션들은 기본적으로 물리적 연결(Socket)을 공유한다. 그러나 domain.xml의 Connection Factory 설정에서 <reconnect-enabled>의 값이 true로 설정된 경우에는 장애 극복을 위해 각각의 커넥션과 물리적 연결이 1대 1 관계가 된다.

연결이 복구될 때 커넥션이 재연결될 뿐만 아니라 커넥션의 상태도 모두 복구된다.

커넥션 상태뿐만 아니라 커넥션 이하의 세션과 커넥션 메시지 수신자(ConnectionConsumer)들도 모두 복구된다.

세션은 Session.close()가 호출되지 않은 경우라면 커넥션이 복구될 때 같이 복구된다. 또한 세션 이하의 메시지 수신자(MessageConsumer)나 메시지 송신자(MessageProducer)들도 세션이 복구될 때 모두 복구된다.

세션에는 여러 가지 객체를 생성하는 메소드들을 가지고 있는데 각 메소드는 발생한 장애를 복구할 때 다음과 같이 동작한다.

본 절에서는 메시지 전송자를 통해서 메시지를 전송할 때 장애가 발생할 경우에 대해서 설명한다.

메시지 송신자의 send 메소드는 메시지가 서버에 전달되어 응답되기까지 blocking된다. 만약, 도중에 장애가 발생할 경우 다음과 같은 상황이 발생한다.

메시지 수신은 크게 동기와 비동기 방법으로 나눠지며 장애가 복구된 경우 동작 방식이 조금씩 다르다. 우선 동기식 메시지 수신하는 경우 장애 복구에 대해서 설명한다.

메시지 수신자에는 MessageConsumer.receive()와 MessageConsumer.receive(long timeout), MessageConsumer.receiveNoWait() 3가지 동기식 메시지 수신 메소드가 있다.

각 메소드 호출할 때 장애가 발생하면 다음과 같이 동작한다.

비동기식 메시지 수신 복구 방법으로 수신한 메시지들은 MessageListener.onMessage 중이거나 MessageListener.onMessage에서 처리되어 acknoweldge 중이거나 미리 가져오기를 통해 클라이언트 큐에 쌓여 있는 메시지들로 나눌 수 있다.

각각의 메시지들에 대해서 JEUS MQ는 다음과 같이 장애를 복구한다.

JEUS MQ의 장애 극복이 클라이언트 애플리케이션에 명확하게 자동으로 처리된다. 그러나 메시지 송수신 과정에서 메시지를 유실할 위험이 있으므로 ExceptionListener를 통해서 이런 메시지들에 대해서 별도로 처리해야 하는 문제점이 있다.

엔터프라이즈 메시징 애플리케이션에서 메시지 유실은 치명적인 문제를 일으킬 수 있다. 메시지 유실을 방지하면서 완벽하게 장애를 극복할 수 있는 유일한 방법은 트랜잭션을 사용하는 것이다.

따라서 다음에 제시하는 방법을 통해서 애플리케이션을 작성할 것을 적극 권장한다.

일반 Java 클라이언트에서는 세션을 생성할 때 Connection.createSession(true, Session.SESSION_TRANSACTED)를 호출하여 생성한다. 이렇게 생성한 세션은 commit()이나 rollback() 호출을 통해서 트랜잭션 내에서 메시지를 송수신할 수 있다.