Понимание тестирования интеграции JMS с Spring SingleConnectionFactory и CachingConnectionFactory

Question

Пожалуйста, помогите понять следующее:

Я использую CachingConnectionFactory в своем приложении и впервые использовал его во время моих jms-тестов, чтобы проверить мою конфигурацию jms, такую ​​как гарантированная доставка, откат / принятие и т. Д.

Я использую Spring's JmsTemplate для отправки и DefaultMessageListenerContainer во время доставки.

1. Я заметил, что это трудно / невозможно при использовании нескольких методов тестирования, запускаемых последовательно Пример: в тестовом методе A я выкидываю исключения в приемнике сообщений (на стороне потребителя), так что происходят повторные попытки. Затем выполняется тест B, и в методе A я выполняю другой тест, но когда я запускаю этот тест, я все еще получаю сообщения о повторных попытках из теста A, которые я явно не хочу. Я очищаю Очередь через jmx между тестами, но все еще получаю эти повторы: (... Я искал и отлаживал ... Я не совсем понимаю, почему эти повторные попытки продолжаются, даже когда я уверен, что очистка происходит правильно. Может быть, это уже было кешировано где-то на сессии ... Я не знаю. Кто-нибудь есть идеи?

2. Я обнаружил, что мне нужно было использовать SingleConnectionFactory во время тестирования. С этой фабрикой соединений повторные попытки исчезают, но я не очень понимаю, почему. Зачем? Я понимаю, что он использует только одно соединение (из ссылки на Spring), и заметил, что он каким-то образом удаляет потребителя после каждого действия отправки, но я не совсем понимаю, что происходит с этими повторными попытками: (... Есть идеи? (Трудно отлаживать из-за многопоточного поведения и трудно найти хорошую информацию об этом в сети) Также использование CachingConnectionFactory только с одним размером кэша сеанса равным 1 не решило проблему повторных попыток.

Спасибо

Answer 1

Исправить непросто: удалять сообщения между тестами.Я пробовал много вещей, как упомянуто выше: остановка / запуск посредника и класса DefaultMessageListenerContainer из Spring, который я использую для потребления своих сообщений.Кажется, все работает до тех пор, пока я не включу, чтобы установить уровень кэширования в DefaultMessageListenerContainer на Consumer, чтобы потребитель кэшировался.Это требуется таким образом, чтобы redeliveryPolicy работал.Тем не менее, это каким-то образом испортило все и сообщения, которые кэшировались с помощью DefaultMessageListenerContainer, как это казалось.

В конце я решил это, просто приняв все сообщения после теста (просто подождите секунду и потребите все Ok), чтобы можно было начать следующий тест.

Answer 2

Лучше всего было бы использовать встроенный брокер и запускать / останавливать его между каждым тестом, убедитесь, что для deleteAllMessagesOnStartup задано значение true, и брокер должен очистить магазин перед вами, что обеспечитполучил чистый лист для каждого теста.Вам также может быть полезно взглянуть на модульные тесты ActiveMQ, это хороший источник примеров того, как брокер может использоваться в автоматизированных тестах.