本文介绍了网络故障后重新连接到ActiveMQ服务器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在使用ActiveMQ 5.8.0通过TCP将Java应用程序连接到另一个系统.请求/回复(与对临时队列的回复同步)在我们的客户端及其相应部分上正常工作.

we are using ActiveMQ 5.8.0 to connect our Java application via TCP to another system.Request/reply (synchronous with reply to temporary queue) works fine with our client and its corresponding part.

但是我们不确定如何处理异常"情况,例如短暂的网络故障.我们正在测试应用程序在套接字重新连接后是否可以继续正常工作.

But we are not sure about how to handle "abnormal" situations like e.g. a short network failure.We are testing if the application can continue its work normally after socket reconnect.

但是直到现在我们还是无法解决这个问题,因为客户端似乎没有按预期自动重新连接到代理.我们曾考虑过自己在自己的TransportListener内启用它,但不建议这样做(请参见 Transport Listener和ActiveMq重新启动,其中ActiveMQ成员Tim Bish暗示使用故障转移协议.但是,如果一个代理发生故障,故障转移只是设法切换到另一个代理,对吗?

But until now we couldn't manage that because the client seems not to automatically reconnect to the broker as expected.We thought about implenting it by ourselves inside an own TransportListener, but this is not recommended (see Transport Listener and ActiveMq restart, where ActiveMQ member Tim Bish hints to use the failover protocol).But the failover just manages to switch to another broker, if one is down, right?

当前,我们仅使用TransportListener来监视日志文件中的连接状态,这会导致一些日志条目,例如following或类似的日志(在下面的长日志中发布).

Currently we are using the TransportListener only to monitor the connection state in the log file, which leads to some log entries like following or similar (posted in long log below).

class ConnectionStateMonitor
    implements TransportListener
{
    @Override
    public void onCommand(Object command)
    {
        logInfo("Producer received: " + command);
    }

    @Override
    public void onException(IOException exception)
    {
        logError("Producer received: " + exception);
    }

    @Override
    public void transportInterupted()
    {
        logError("Producer received transport interuption.");
    }

    @Override
    public void transportResumed()
    {
        logInfo("Producer received transport resumption.");
    }
}

很抱歉,在下面发布了带有堆栈跟踪的长日志摘录,但也许有人会立即看到缺少的内容.

Sorry, for posting a long log excerpt with stacktraces below, but maybe someone immediately sees what is missing.

我们当前正在使用以下设置:

We are currently working with following settings:

  • wireFormat.maxInactivityDuration = 20000
  • 最长等待回复时间:10000毫秒

有什么想法可以解决该问题(以及如何格式化下面的日志)?

Any ideas how to solve that problem (and how to format pretty the log below) ?

提前谢谢!

推荐答案

听起来像故障转移绝对是您要使用的东西.您无需故障转移到另一个代理-URI只是指示客户端库重新连接,因此您可以执行以下操作:

It sounds like failover is definitely the thing that you want to use. You don't need to failover to another broker - the URI simply instructs the client library to reconnect, so you can do something like:

failover:(tcp://myBroker:61616)

这篇关于网络故障后重新连接到ActiveMQ服务器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-04 04:50
查看更多