두 가지 방법으로 MDB 예외를 처리하는 데 도움이 필요합니다.

Question

메시지 처리 중에 두 가지 유형의 문제를 처리하려고합니다.

첫 번째 문제는 원격 데이터베이스가 다운 된 경우입니다. 이 경우 메시지는 처리를 중지하고 나중에 다시 시도해야합니다. 이 메시지는 절대로 DLQ로 보내지 않아야하며 원격 데이터베이스가 가동 될 때까지 계속 시도해야합니다.

두 번째 문제는 메시지에 문제가있는 경우입니다. 이 경우 DLQ로 이동해야합니다.

다음 코드를 어떻게 구성해야합니까?

@Override 
public void onMessage(Message message) { 
    try { 

    // Do some processing 
    messageProcessing(message); // Should DLQ if message is bad 

    // Save to the database 
    putNamedLocation(message); // <<--- Exception when external DB is down 

    } catch (Exception e) { 
     logger.error(e.getMessage()); 
     mdc.setRollbackOnly(); 
    } 
} 

Answer 1

MDB의 코드 본문에서 불량 메시지를 확실하게 검색 할 수 있다고 가정하면 잘못된 메시지를 직접 DLQ에 기록합니다. 이렇게하면 오류를 분류하고 필요에 따라 다른 유형의 불량 메시지를 다른 "DLQ- 유사"대기열에 보내거나 DLQ 대기 메시지에 수명을 적용하여 희망이없는 메시지가 표시되지 않도록 할 수 있습니다. 항상 처리중인 유형의 메시지는 대기열에 저장되지 않습니다. ConnectionFactory 및 Queue 참조를 참조하는 MDB 클래스에 @Resource 주석이 추가 된 인스턴스 변수를 추가하여 메시지를 대상 DLQ로 보내도록 지원할 수 있습니다. 결론은 오류 및 DLQ 메시지를 사용자가 직접 감지했는지 확인하는 것입니다.

DB가 다운 된 경우 연결을 얻거나 업데이트를 작성할 때 예외를 포착하여이를 감지 할 수 있습니다. 이 경우 자원을 정리하고 RuntimeException을 던집니다. 이 메시지가 다시 전달되게합니다,하지만 당신은 두 가지에 대한 JMS 구성을 확인하는 것이 좋습니다 : 그렇지 않으면 카운트가 이상 체크합니다,

1. 이 최대 - 재 전달 계수가 충분히 높은 있는지 확인하고 메시지가 될 것입니다 결국 어쨌든 DLQed.
2. JMS 구현에서 지원하는 경우 거부 된 메시지에 다시 배달 지연을 추가하여 DB가 다시 돌아올 때까지 기다리십시오. 그렇지 않으면 메시지가 배달/거부 루프에서 끝없이 회전합니다. (당신의 JMS 구현 스피어 MQ처럼 redilvery 지연을 지원하지 않는 경우 까다 롭습니다)

는 MDB가 MDB에 배달을 중지 (나중에 다시 시작)을 위해 당신이 JBoss의 JMX 관리 인터페이스를 사용할 수 있습니다, # 2를 방지하려면 . 그러나 MDB가 처리를 완료 할 때까지 대기하기 때문에 메시지를 처리하는 동일한 스레드의 MDB 내부에서이 작업을 수행 할 수 없습니다. MDB가 처리를 완료 할 때까지 대기합니다. 왜냐하면 ... [등등] 그래서 ... 최선의 방법은 DB를 폴링하는 일종의 보초를 시작하는 것입니다. MDB를 찾은 다음 다시 찾으면 다시 시작합니다. 이를 수행하는 방법에 대한 내용은 question을 참조하십시오.

마지막 부분은 메시지 유효성 검사로 인한 예상치 못한 예외를 처리하는 데 도움이됩니다. (즉, DB는 문제가 없지만 어떤 이유로 메시지가 완전히 fubar 인 경우 캐리지되지 않은 예외가 발생하여 메시지가 다시 전달됩니다). 다운 DB 메시지가 몇 번이나 (보초로 인해) 재 배달되지 않아야하므로 메시지의 재 배달 횟수를 확인할 수 있습니다. 그리고 엄청나게 높으면 포이즌 메시지를 가지고 있다는 사실을 알게되거나 DLQ 그것.

희망이 있습니다.