Нужна помощь для обработки исключения 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

Предполагая, что вы можете обнаружить плохие сообщения окончательно в коде теле ПДБА, я хотел бы написать плохие сообщения в DLQ непосредственно. Это дает вам немного больше свободы, чтобы, возможно, классифицировать эту ошибку и, при необходимости, отправлять разные типы плохих сообщений в разные очереди «DLQ-Like» и/или применять время от времени к сообщениям DLQ, чтобы никакие надежды, сообщения о непрерывном обращении не накапливаются в очереди навсегда. Вы можете добавить переменные экземпляра @Resource для вашего класса MDB, ссылаясь на ссылки ConnectionFactory и Queue, чтобы поддерживать отправку сообщений в целевой DLQ. Суть в том, что вы обнаружите ошибку и DLQ сообщение самостоятельно.

Что касается того, что DB находится внизу, вы можете обнаружить это, воспользовавшись исключениями при приобретении соединения или написании обновлений. В этом случае очистите ресурсы и выбросите исключение RuntimeException. Это приведет к тому, чтобы сообщение было повторно доставлено, но вы хотите, чтобы проверить конфигурацию JMS для двух вещей:

1. Убедитесь, что счетчик не более-обратной передачи достаточно высок, в противном случае счетчик будет тикать снова и сообщение будет DLQed в конце концов в любом случае.
2. Если ваша реализация JMS поддерживает его, добавьте задержку пересылки для отклоненных сообщений, чтобы дать некоторое время для восстановления базы данных, в противном случае ваши сообщения будут бесконечно вращаться в цикле доставки/отклонения.

Чтобы избежать # 2 (который является сложным, если ваша реализация JMS не поддерживает redilvery задержки, как WebSphereMQ), вы можете использовать интерфейс управления JBoss JMX для MDB, чтобы остановить (а затем рестарт) доставка на MDB , Однако вы не можете сделать это внутри MDB в том же потоке, который обрабатывает сообщение, потому что MDB будет ожидать завершения обработки сообщения, чего не может, потому что он ждет остановки MDB, что может потому что ... [и так далее], так что ... лучше всего начать какой-то часовой, который опросит БД, и когда он найдет его, остановит MDB и, когда он снова найдет его, перезапустит его. См. Этот question для описания того, как это сделать.

Эта последняя часть должна помочь справиться с любыми неожиданными исключениями, возникшими в результате проверки сообщений. (т. е. БД в порядке, но по какой-то причине сообщение является полностью фубарным, что приводит к неперехваченным исключениям, которые заставляют сообщение пересылаться повторно). Поскольку сообщения с более низким БД не следует переадресовывать более чем несколько раз (из-за вашего часового), вы можете проверить счет повторной доставки сообщения, и если он смехотворно высок, то вы знаете, что у вас есть ядовитое сообщение, и вы можете его остановить, или DLQ Это.

Надеюсь, это полезно.