Клиент JMS не может установить соединение sh после аварийного переключения брокера с использованием транспорта аварийного переключения - PullRequest
Новая
       42

Клиент JMS не может установить соединение sh после аварийного переключения брокера с использованием транспорта аварийного переключения

0 голосов
/ 20 января 2020

Согласно https://activemq.apache.org/failover-transport-reference.html, мы используем строку подключения в нашем JmsListener согласно синтаксису, и значение равно 

 failover:(tcp://activemq-01:61616,tcp://activemq-02:61616)?randomize=false&maxReconnectDelay=3000&maxReconnectAttempts=50"

Мы используем 

 ActiveMQ : 5.14.5
 Spring : spring-boot-starter-activemq-2.2.0.RELEASE

Наши бины определены ниже 

 @Bean
public ConnectionFactory connectionFactory() {

    ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory();
    try {
        connectionFactory.setBrokerURL("failover:(tcp://activemq-01:61616,tcp://activemq-02:61616)?randomize=false&maxReconnectDelay=3000&maxReconnectAttempts=50");
        connectionFactory.setUserName("abcxyz");
        connectionFactory.setPassword("abcxyz");
    }catch(Exception e) {
        e.printStackTrace();
    }
    return connectionFactory;
}      

@Bean
public JmsListenerContainerFactory<?> topicListenerFactory(ConnectionFactory connectionFactory,
        DefaultJmsListenerContainerFactoryConfigurer configurer) {

    DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
    factory.setSubscriptionDurable(true);
    factory.setClientId("ClientID");
    configurer.configure(factory, connectionFactory);
    factory.setPubSubDomain(true);
    return factory;
}

Поэтому я попытался сбить одного из брокеров и подтвердить, что другой брокер получил блокировку и стал мастером. но клиент все еще пытался подключиться к первому посреднику и не смог. Он так и не смог подключиться ко второму брокеру. Я заметил похожее поведение как для очереди, так и для прослушивателя topi c.

Прослушиватель очереди -> 

   @JmsListener(destination = "MYQUEUE")
   public void receiveMessageFromQueue(String message) {
         System.out.println("Message recv from queue ->" + message);
   }

Topi c Прослушиватель -> 

   @JmsListener(destination = "MYTOPIC",containerFactory = "topicListenerFactory")
   public void receiveMessageFromQueue(String message) {
         System.out.println("Message recv from queue ->" + message);
   }

Помимо randomize, maxReconnectDelay, maxReconnectAttempts - есть ли другие варианты, которые будут использоваться для восстановления после отказа.

Любая помощь приветствуется.

Спасибо

...