了解 Spring SingleConnectionFactory 和 CachingConnectionFactory 的 JMS 集成测试

发布于 2024-10-22 11:43:36 字数 785 浏览 1 评论 0原文

请帮助理解以下内容:

我在我的应用程序中使用 CachingConnectionFactory ,并首先在 jms 测试期间使用它来测试我的 jms 配置,如保证交付、回滚/提交等。

我正在使用 Spring 的 < code>JmsTemplate 用于发送,DefaultMessageListenerContainer 在传递期间。

  1. 我注意到,当使用多个连续运行的测试方法时,这是很难/不可能的 示例:在测试方法 AI 中,消息侦听器(消费者端)抛出异常,从而发生重试。 然后运行测试 B,并在方法 AI 中执行不同的测试,但是当我开始此测试时,我仍然收到来自测试 A 的重试消息,这显然是我不想要的。 我在测试之间通过 jmx 清除队列,但仍然收到这些重试:(... 我搜索和调试...我不完全明白为什么这些重试不断发生,即使我确信清除正确发生。也许它已经缓存在会话中的某个地方......我不知道。有人知道吗?

  2. 我发现在测试过程中我需要使用SingleConnectionFactory。有了这个连接工厂,重试就会消失,但我不太明白为什么。为什么? 我知道它只使用一个连接(来自 Spring 参考),并注意到它在每次发送操作后都会以某种方式删除消费者,但我真的不明白这些重试会发生什么:(...知道吗? (由于多线程行为,很难调试,并且很难在网络上找到有关它的良好信息) 另外,仅使用一个会话缓存大小为 1 的 CachingConnectionFactory 并不能解决重试问题。

谢谢

Please some help understanding the following:

I am using CachingConnectionFactory in my app and first used it during my jms tests to test my jms config like guaranteed delivery, rollback/commit, etc..

I am using Spring's JmsTemplate for sending and DefaultMessageListenerContainer during delivery.

  1. I noticed that this is hard/impossible when using several test methods run sequential
    Example: in test method A I throw exceptions in the Message listener (consumer side) such that retries occur.
    Then test B is run and in method A I do a different test, but when I start this test I still get retry messages from test A, which I clearly not want.
    I purge the Queue through jmx between tests, but still receive these retries :(...
    I searched and debugged... I don't exactly understand why these retries keep comming up, even when I am sure that the purge occur correctly. Maybe it was already cached somewhere in the session... I don't know. Anybody any idea?

  2. I found out that I needed to use the SingleConnectionFactory during testing. With this connection factory the retries disappear, but I don't really understand why. Why?
    I understand that it uses only one connection (from the Spring ref), and noticed that it somehow removes the consumer after every send action, but I don't really understand what happen with these retries :(... Any idea?
    (It's hard to debug because of the multi threading behavior and difficult to find good information about it on the web)
    Also using CachingConnectionFactory with only one session cache size of 1 didn't solve the retry issue.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

土豪我们做朋友吧 2024-10-29 11:43:36

最好的选择可能是使用 嵌入式代理并在每次测试之间启动/停止它,确保deleteAllMessagesOnStartup设置为true,并且代理应该清除您面前的存储,这将确保您为每个测试都有一个干净的状态。您还可能会从查看 ActiveMQ 的单元测试中受益,它是有关如何在自动化测试中使用代理的示例的良好来源。

Best bet would probably to use an embedded broker and start/stop it between each test, make sure deleteAllMessagesOnStartup is set to true and the broker should purge the store fore you, which will ensure you've got a clean slate for each test. You might also benefit from having a look at ActiveMQ's unit tests, it's a good source of examples of how the broker can be used in automated tests.

我不会写诗 2024-10-29 11:43:36

这不是一件容易修复的事情:删除测试之间的消息。
我尝试了很多事情,就像上面提到的那样:停止/启动代理和我用来消费消息的 Spring 类 DefaultMessageListenerContainer。
这一切似乎都有效,直到我将 DefaultMessageListenerContainer 中的缓存级别设置为 Consumer,以便缓存消费者。
这是重新投递策略发挥作用所必需的。
然而,这似乎以某种方式搞乱了 DefaultMessageListenerContainer 缓存的所有内容和消息。

最后,我通过简单地在测试后消耗所有消息(只需等待一秒钟并消耗所有消息即可解决)来解决它,以便下一个测试可以开始。

It's not an easy thing to fix: remove the messages between tests.
I tried many thingssss, like mentioned above: stop/start the broker and the class DefaultMessageListenerContainer of Spring that I use to consume my messages.
It all seem to work until I turned I set the cache level in DefaultMessageListenerContainer to Consumer such that the consumer is cached.
That is required such that the redeliveryPolicy works.
However, this messed up everything and messages where cached by DefaultMessageListenerContainer in some way, as it seemed.

At the end, I solved it by simple consuming all messages after a test (just wait a second and consume all Ok), such that the next test can begin.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文