当网络连接断开时,javax.jms.ExceptionListener是否会延迟onException回调?

发布于 2024-08-03 14:25:19 字数 510 浏览 9 评论 0原文

我正在使用 Websphere Application Server (WAS) 6.1 的 JMS 默认消息传递提供程序。我的远程客户端应用程序创建一个连接,然后执行 setExceptionListener 来注册回调。

当我简单地使用 WAS Integrated Solutions Console 停止消息传递引擎时,我的应用程序将按预期运行,即立即调用 onException 并且我的应用程序会做出相应反应。但是,当我拔掉网络电缆时,onException 回调在 30 到 60 秒之间不会被回调。

丑陋的结果是,我的应用程序只是尝试在这 30 到 60 秒的时间范围内不断向 WAS 发送消息,而这些消息却丢失了。我已经进行了多次搜索,试图找到有关 ExceptionListener 的更多信息(例如,是否有一些配置参数用于指定回调超时),但没有取得任何成功。

希望这对那里的人来说是有意义的。有什么建议可以让我更快地检测到电缆“切断”情况吗?感谢您的帮助。

-克里斯

I'm using Websphere Application Server (WAS) 6.1's default messaging provider for JMS. My remote client application creates a connection, then does a setExceptionListener to register the callback.

When I simply stop the messaging engine using the WAS Integrated Solutions Console, my app behaves as expected, i.e., onException is called immediately and my app reacts accordingly. However, when I pull the network cable, the onException callback does not get called back for somewhere between 30 and 60 seconds.

The ugly result is that my app just tries to keep sending messages to WAS during this 30 to 60 second time frame and those messages just get lost. I've done several searches trying to find out more about the ExceptionListener (e.g., is there some configuration parameter used to specify a callback timeout), but have not had any success.

Hopefully, this makes sense to someone out there. Any suggestions how I might be able to detect the cable "cut" scenario more quickly? Thanks for your help.

-Kris

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

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

发布评论

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

评论(1

救赎№ 2024-08-10 14:25:19

您没有定义 30 秒的 TCP 超时吗?
如果是这样,则 MQ 已将其职责暂时移交给 JVM/OS,并等待其通过其请求的任何网络相关操作进行 ACK。也许尝试降低 TCP 超时值...

You don't happen to have a 30 second TCP timeout defined?
If so, then MQ has handed over its responsibility temporarily to the JVM/OS and is waiting for for it to ACK with whatever network related operation it has requested. Perhaps try lowering the TCP timeout value...

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