Comments 6
Kafka is not JMS compliant
Исправьте в тексте. Это достаточно критично в некоторых случаях. Например, Kafka, не меняет порядок сообщений, тогда как JMS поддерживает приоритезацию, которая меняет порядок сообщений.
Получается, опираться на ACK надёжнее? Наличие явного подтверждения можно проверить статическим анализом кода, тогда как управление потоком исполнения через исключения всегда являлось антипаттерном.
Вопрос в том, когда сообщение должно возвращаться в очередь. Если достаточно возвращать сообщение в очередь в случае рестарта сервиса, а в случае ошибок достаточно логов/мониторинга, то можно использовать транзакции и не выбрасывать никаких исключений.
CLIENT_ACKNOWLEDGE подходит для довольно специфических случаев, таких, как описан в примере: сервис может подолгу формировать документы, и важно гарантировать поступление документа в хранилище.
При этом тут есть свои риски, например, можно допустить где-нибудь просчёт и заполнить очередь неподтверждёнными сообщениями.
Спасибо за статью, это пригодится. Но я всё ещё не понимаю, как обеспечить надежность обработки сообщений при использовании режима CLIENT_ACKNOWLEDGE в случае долгосрочных задач, если сервис может рестартовать или соединение с брокером разрывается?
Тонкости JMS API: как не терять сообщения