Active 서버

장애가 없을 때 클라이언트의 요청을 받아서 처리하는 메인 서버이다.

Standby 서버

Active 서버에 장애가 발생하면 Active 서버가 수행하던 서비스들을 이어받아서 수행하는 백업 서버이다.

Active 서버 설정

Active 서버 설정은 화면에서 다음과 같이 'Fail Over'를 체크하고 'Active'를 선택하거나 또는 'Fail Over' 항목을 체크하지 않는다. 즉, 다음의 두 화면은 동일한 설정이다.

Standby 서버 설정

Standby 서버의 설정은 화면에서 아래와 같이 'Fail Over'를 체크하고, 'Standby'로 선택한다.

[그림 5.5] 장애 극복 설정 - Standby 서버 설정

저널 로그 Persistence Store

저널 로그를 Persistence Store로 사용할 경우에는 저널 로그 베이스 디렉터리(저널 로그 설정의 'Base Dir'의 값)는 Active 서버와 Standby 서버가 모두 접근 가능한 곳에 위치해야 한다. 이를 위해서 SAN과 같은 디스크 공유 하드웨어를 구성하고 그 위에 저널 로그의 베이스 디렉터리를 생성해야 한다.

JDBC Persistence Store

JDBC를 Persistence Store로 사용할 경우에는 단순히 WebAdmin에 설정된 데이터소스를 지정하면 된다. 다만, 데이터베이스도 장애가 발생하여 서비스를 할 수 없는 경우가 있기 때문에 Tibero의 TAC이나 OracleDB의 RAC같은 클러스터링 기술을 사용하여 데이터베이스도 장애 극복을 위한 구성을 해야 한다.

시작(start) 상태

메시지 수신을 위해서 Connection.start()를 호출한 경우 발생한 장애가 복구되면 시작 상태가 복구되어 메시지 수신을 계속할 수 있다.

정지(stop) 상태

메시지 수신을 중지하기 위해서 Connection.stop()을 호출한 경우 장애가 복구되면 정지 상태가 복구되어 더 이상 메시지 수신을 하지 않는다.

세션(Session) 복구

커넥션을 통해서 생성된 세션은 장애 발생 이전에 Session.close()가 호출되지 않은 경우에 커넥션 장애가 복구되면 같이 복구된다. 자세한 내용은 “5.3.6. 세션 복구”을 참고한다

커넥션 메시지 수신자(ConnectionConsumer) 복구

커넥션을 통해서 생성된 커넥션 메시지 수신자는 장애 발생 이전에 ConnectionConsumer.close()가 호출되지 않았다면 커넥션이 복구될 때 같이 복구되며 커넥션이 시작 상태인 경우 메시지 수신을 계속하게 된다. 단, 장애 이전에 수신했던 메시지들은 모두 서버로 되돌려 보내지고 새로 받게 되므로 이후 수신된 메시지들의 Message.getJMSRedelived()가 true가 될 수 있다.

메시지 생성 메소드

메시지를 생성하는 메소드들은 장애 여부와 상관없이 항상 바로 생성이 된다.

createBytesMessage()
createMapMessage()
createMessage()
createObjectMessage()
createObjectMessage(Serializable object)
createStreamMessage()
createTextMessage()
createTextMessage(String text)

큐 브라우저 생성 메소드

큐 브라우저를 생성하는 메소드는 장애가 복구된 후에도 요청을 완료한다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

createBrowser(Queue queue)
createBrowser(Queue queue,String messageSelector)

Destination 생성 메소드

Destination을 생성하는 메소드들은 장애가 복구된 후에도 생성 요청을 완료한다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

createQueue(String queueName)
createTopic(String topicName)

임시 Destination 생성 메소드

임시 Destination을 생성하는 메소드들은 장애와 상관없이 생성 요청을 완료한다.

createTemporaryQueue()
createTemporaryTopic()

메시지 수신자 생성 메소드

메시지 수신자를 생성하는 메소드들은 장애가 복구된 후에도 생성 요청을 완료한다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

createConsumer(Destination destination)
createConsumer(Destination destination, java.lang.String messageSelector)
createConsumer(Destination destination, java.lang.String messageSelector,boolean NoLocal)

Durable 메시지 수신자 생성 메소드

Durable 메시지 수신자를 생성하는 메소드들은 장애가 복구된 후에도 생성 요청을 완료한다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

createDurableSubscriber(Topic topic, String name)
createDurableSubscriber(Topic topic,String name, String messageSelector,boolean noLocal)

메시지 송신자 생성 메소드

메시지 송신자를 생성하는 메소드는 장애가 복구된 후에도 생성 요청을 완료한다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

createProducer(Destination destination)

commit()

트랜잭션 세션에서 생성한 메시지 수신자와 메시지 송신자를 이용하여 메시지를 수신하거나 전송하는 중에 장애가 발생한 경우 이후 첫 번째로 호출되는 commit은 "javax.jms.TransactionRolledBackException"을 발생하며 rollback된다. commit 시점에 commit할 메시지가 없다면 이 예외는 발생하지 않는다. 장애에 의해 commit이 실패된 후 호출되는 commit은 모두 정상적으로 동작한다.

만약 commit 중에 장애가 발생했는데 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다. 이 경우 commit 여부는 알 수 없으며 관리 도구를 통해서 commit 여부를 확인해야 한다.

rollback()

rollback은 장애 극복 후에도 rollback 요청을 완료한다. 만약 rollback 중에 장애가 발생했는데 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다. rollback의 경우 JMSException이 발생해도 rollback되는 것을 보장할 수 있다.

send를 호출했지만 메시지가 아직 전송되지 않은 경우

이 경우 장애가 복구된 후에 메시지는 서버로 전송되고 정상 처리된다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

send를 호출하고 메시지가 서버에서 처리된 후에 네트워크에 장애가 발생한 경우

이 경우 장애가 복구되어 다시 서버에 접속하면 응답 메시지를 받아 정상적으로 처리된다. 만약 RequestBlockingTime이 지난 후에도 장애가 복구되지 않는다면 JMSException이 발생한다.

send를 호출하고 메시지가 서버에서 처리된 후에 서버에서 장애가 발생하였고 그 장애가 복구된 경우

이 경우 장애가 복구되어 다시 서버에 접속해도 메시지 전송 여부를 알 수 없으므로 RequestBlockingTime만큼 기다리다가 ExceptionListener를 통해서 "jeus.jms.common.message.MessageSendException"을 통보한다.

send를 호출하고 메시지가 서버에서 처리되기 전에 네트워크나 서버에 장애가 발생한 경우

이 경우에도 위의 경우와 마찬가지로 복구된 서버에 다시 접속해도 메시지 전송 여부를 알 수 없으므로 RequestBlockingTime만큼 기다리다가 ExceptionListener를 통해서 "jeus.jms.common.message.MessageSendException"을 통보한다.

receive()

receive() 메소드의 경우 원래 메시지를 수신할 때까지 blocking되지만, 장애가 발생하면 언제 복구될 지 알 수 없으므로 대기시간을 RequestBlockingTime으로 변경한다. 만약 시간 내에 장애가 복구되면 메시지 수신을 요청하는 메시지를 다시 보내서 메시지를 수신하고 그렇지 않으면 JMSException이 발생한다.

Session.AUTO_ACKNOWLEDGE로 설정한 경우에는 메시지를 수신하고 클라이언트에 메시지를 넘겨주기 전에 acknowledge를 서버에 전송한다. 이때 장애가 발생하면 acknowledge 실패한 메시지에 대해서 ExceptionListener를 통해 jeus.jms.common.message.MessageAcknowledgeException을 통보한다. 이 Exception은 메시지 acknowledge 중에 장애가 발생해서 메시지가 재전송(Redelivered)될 수 있음을 알려준다.

receive(long timeout)

receive(long timeout) 메소드는 원래 메시지를 수신할 때까지 blocking되지만, 장애가 발생하면 언제 복구될지 알 수 없으므로 타임아웃이 RequestBlockingTime보다 큰 경우 제한 시간을 RequestBlockingTime으로 변경한다. 만약, 제한 시한 내에 장애가 복구되면 메시지 수신을 요청하는 메시지를 다시 보내어 메시지를 수신하고 그렇지 않으면 JMSException이 발생한다.

Session.AUTO_ACKNOWLEDGE로 설정한 경우 메시지를 수신하고 클라이언트에 메시지를 넘겨주기 전에 acknowledge를 서버에 전송한다. 이때 장애가 발생하면 acknowledge 실패한 메시지에 대해서 ExceptionListener를 통해서 jeus.jms.common.message.MessageAcknowledgeException을 통보한다. 이 Exception은 메시지 acknowledge 중에 장애가 발생하여 메시지가 재전송(Redelivered)될 수 있음을 알려준다.

receiveNoWait()

receiveNoWait() 메소드는 원래 메시지를 수신하지 않아도 blocking되지 않는다. 따라서 장애가 발생해도 바로 반환된다.

onMessage 중에 장애가 발생하면 장애가 복구된 후에 acknoweldge가 전송되므로 정상적으로 처리된다.

onMessage가 완료된 후 acknoweldge가 전송되는 중에 장애가 발생하면 acknowledge 실패한 메시지에 대해서 ExceptionListener를 통해서 jeus.jms.common.message.MessageAcknowledgeException을 통보한다. 이 Exception은 메시지 acknowledge 중에 장애가 발생하여 메시지가 재전송(Redelivered)될 수 있음을 알려준다.

미리 가져오기로 클라이언트 큐에 쌓여 있는 메시지들은 장애 극복 후에 모두 서버로 되돌려 보내지며 나중에 다시 클라이언트로 전송된다. 이 메시지들의 Message.getJMSRedelivered()의 값은 true가 될 수 있다.

J2EE 환경에서는 반드시 트랜잭션 내에서 메시지를 송수신한다.

서블릿의 경우 UserTransaction을 JNDI로부터 Lookup하여 UserTransaction 내에서 메시지를 송수신한다.

EJB의 경우 EJB 메소드의 트랜잭션 속성(TransactionAttribute)을 "Required"나 "RequireNew"로 설정해서 항상 트랜잭션 내에서 메시지를 송수신한다.