如何找出JMS Connection是否存在？ [英] How to find out if JMS Connection is there?
问题描述
在JMS中，很容易发现连接是否丢失，发生异常。但是如何确定连接是否再次出现？
In JMS it is easy to find out if a connection is lost, a exception happens. But how do I find out if the connection is there again?
场景：我使用JMS与我的服务器通信。现在我的连接断开（服务器关闭），这导致异常。到现在为止还挺好。如果服务器再次启动并重新建立连接，我该如何知道？
Scenario: I use JMS to communicate with my server. Now my connection breaks (server is down), which results in a exception. So far so good. If the server is up again and the connection is reestablished, how do I know that?
我没有看到任何能够提供此类信息的监听器。
I don't see any Listeners which would facilitate such information.
推荐答案
啊......旧的异常处理/重新连接难题。
Ahhh...the old exception handling/reconnection conundrum.
有些传输提供商会自动为您和一些使应用程序驱动器重新连接重新连接您的应用程序。通常，重新连接会将异常隐藏在应用程序之外。不好的一面是，如果所有远程消息传递节点都已关闭，您不希望应用程序永久挂起，因此最终，必须包含一些重新连接逻辑。
There are some transport providers that will automatically reconnect your application for you and some who make the app drive reconnection. In general the reconnections hide the exception from the application. The down side is that you don't want the app to hang forever if all the remote messaging nodes are down so ultimately, you must include some reconnection logic.
现在这里有趣的部分 - 如何以提供商中立的方式处理异常？ JMS异常实际上毫无价值。例如，安全性异常可能是Java安全策略过于严格，文件系统权限过于严格，LDAP凭据失败，传输连接失败，队列或主题打开失败或任何其他许多与安全相关的问题。它是链接的异常，它具有来自传输提供程序的详细信息，可以帮助调试问题。我的客户一般采取三种不同方法中的一种...
Now here's the interesting part - how do you handle the exceptions in a provider neutral way? The JMS exception is practically worthless. For example, a "security exception" can be that the Java security policies are too restrictive, that the file system permissions are too restrictive, that the LDAP credentials failed, that the connection to the transport failed, that the open of the queue or topic failed or any of dozens of other security-related problems. It's the linked exception that has the details from the transport provider that really help debug the problem. My clients have generally taken one of three different approaches here...
- 将所有错误视为相同。关闭所有对象并重新初始化它们。这是JMS portable。
- 允许应用程序检查链接的异常，以区分致命错误和瞬态错误（即auth错误与队列已满）。不是提供者可移植的。
- 特定于提供者的错误处理类。另外两个的混合。
在您的情况下，队列和主题对象可能仅在原始连接的上下文中有效。假设提供者自动重新连接您获得异常的事实意味着重新连接失败，并且无法恢复队列和主题对象的上下文。关闭所有对象并重新连接。
In your case, the queue and topic objects are probably only valid in the context of the original connection. Assuming a provider who reconnects automatically the fact that you got an exception means reconnect failed and the context for queue and topic objects could not be restored. Close all objects and reconnect.
是否要执行更多特定于提供程序的操作，例如区分瞬态错误和永久错误，这是依赖于的事情之一，而您我必须根据具体情况来解决这个问题。
Whether you want to do something more provider-specific such as distinguish between transient and permanent errors is one of those "it depends" things and you'll have to figure that out on a case-by-case basis.
这篇关于如何找出JMS Connection是否存在？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
