Apache NMS - 如何确定连接是否已启动

发布于 2025-01-08 09:16:58 字数 1487 浏览 0 评论 0原文

我在 Apache NMS 的一些问题上遇到了麻烦。部分原因可能是我自己对平台缺乏了解。

本质上,我有一个 NMS STOMP 客户端,用于通过 STOMP 发送和接收 AMQ 消息。 API 看起来有点像这样:

internal sealed class NMSStompClient : IDisposable
{
    public bool IsConnected { get; }

    public void Connect(Uri uri, string userId, string password, TimeSpan timeout);

    public void Disconnect();

    public void Send(IDestination destination, IDestination replyDestination, long sessionId, int correlationId, byte[] messageBytes, TimeSpan timeout);

    public IDisposable Subscribe(IDestination destination, Action<IMessage> messageHandler, Action<IMessage, Exception> errorHandler);
}

我试图让集成测试始终通过,但当我增加 AMQ 关闭的时间(10 秒通过,60 秒失败)时,它们总是失败。经过大量的调试和跟踪后,我发现问题似乎源于我的 IsConnected 实现(或者,至少,这是问题的部分):

public bool IsConnected
{
    // connection is Apache.NMS.IConnection
    // session is Apache.NMS.Stomp.Session
    get { return this.connection != null && this.connection.IsStarted && this.session != null && this.session.Connection == this.connection; }
}

我通过反复试验得出了这个实现。我根本找不到一种简单的方法来确定连接是否“正常”。我在 IConnectionSession 上找不到可以告诉我这一点的属性。

我知道 ConnectionInterruptedListenerConnectionResumedListenerExceptionListener 事件,但在我的集成测试期间引发的唯一事件是 ExceptionListener< /代码>。此外,我知道在使用故障转移时根本不会引发它们,而我正在生产中。

谁能帮助我可靠地确定连接是否已建立?或者也许可以澄清我可能有的任何误解?

I'm having a hell of a time with some Apache NMS issues. Part of this may be my own lack of understanding of the platform.

In essence, I have an NMS STOMP client that I use to send and receive AMQ messages via STOMP. The API looks a bit like this:

internal sealed class NMSStompClient : IDisposable
{
    public bool IsConnected { get; }

    public void Connect(Uri uri, string userId, string password, TimeSpan timeout);

    public void Disconnect();

    public void Send(IDestination destination, IDestination replyDestination, long sessionId, int correlationId, byte[] messageBytes, TimeSpan timeout);

    public IDisposable Subscribe(IDestination destination, Action<IMessage> messageHandler, Action<IMessage, Exception> errorHandler);
}

I'm attempting to get my integration tests to pass consistently, but they always fail when I increase the amount of time that AMQ is down for (passes at 10 seconds, fails at 60). After excruciating amounts of debugging and tracing, I've found that the problem appears to stem from my IsConnected implementation (or, at least, this is part of the problem):

public bool IsConnected
{
    // connection is Apache.NMS.IConnection
    // session is Apache.NMS.Stomp.Session
    get { return this.connection != null && this.connection.IsStarted && this.session != null && this.session.Connection == this.connection; }
}

I arrived at this implementation through trial and error. I simply could not find a simple way to determine whether the connection was "up". There is no property that I can find on either IConnection or Session that will tell me this.

I'm aware of the ConnectionInterruptedListener, ConnectionResumedListener, and ExceptionListener events, but the only one raised during my integration test is ExceptionListener. Moreover, I understand they aren't raised at all when using failover, which I am in production.

Can anyone help me to reliably determine whether the connection is up or not? Or perhaps clear up any misunderstanding I may have?

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

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

发布评论

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

评论(1

阪姬 2025-01-15 09:16:58

Apache.NMS.Stomp 客户端确实有一个故障转移传输,它将调用中断和恢复方法,但是在使用故障转移时,您实际上不需要关心这些,因为故障转移传输将为您处理重新连接的事情。当使用直接 TCP 连接时,您只会看到 ExceptionListener 被调用,因为从 tcp 传输的角度来看,一旦失败就失败了,因此异常是适当的。

您可以做出一般情况假设,当您的客户端在其 ExceptionListener 侦听器上收到回调时,连接状态已失败,并执行您需要的任何重新连接操作,尽管如果您使用故障转移传输,它将为您处理,因此不需要任何工作就你而言。

The Apache.NMS.Stomp client does indeed have a failover transport that will call the interrupted and resumed methods however when using failover you don't really need to care about those since the failover transport will deal with reconnecting things for you. When using a straight TCP connection you will only see the ExceptionListener invoked because from the point of view of the tcp transport, once its failed its failed, so an exception is appropriate.

You can make the general case assumption that when your client gets a callback on its ExceptionListener listener that the connection state is failed and do whatever reconnect you need to, although if you use the failover transport it will be handled for you, so no work needed on your part.

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