RabbitMQ удаления очереди не может освободить соединение

Question

на моей Java программы, некоторые из типов сообщений, передаваемых по очереди RabbitMQ, как показано ниже:

if(!con.isConnected()){ 
     log.error("Not connected !!!"); 

     return false; 
} 
con.getChannel().basicPublish("",queueName, MessageProperties.PERSISTENT_BASIC, bytes) 

1. Я удаленных очередей с помощью управления RabbitMQ GUI плагин
2. пытаются отправить сообщение по этой удаленной очереди

Результат: очередей были удалены из RabbitMQ GUI, но когда я пытаюсь отправить Сообща e над этими удаленными очередями RabbitMQ, соединение все еще живое. (con.isConnected() == true) Мне нужно найти способ прослушивания очереди, если она удалена, я не должен отправлять какое-либо сообщение в удаленную очередь.

Примечание: после удаления очереди я не перезапускаю RabbitMQ.

создание канала:

channel = connection.createChannel(); 
channel.queueDeclare(prop.getQueueName(), true, false, false, null); 

пример кода канала, очередь, обмен создание:

ConnectionFactory cf = new ConnectionFactory(); 
    cf.setUsername("guest"); 
    cf.setPassword("guest"); 
    cf.setHost("localhost"); 
    cf.setPort(5672); 
    cf.setAutomaticRecoveryEnabled(true); 
    cf.setConnectionTimeout(10000); 
    cf.setNetworkRecoveryInterval(10000); 
    cf.setTopologyRecoveryEnabled(true); 
    cf.setRequestedHeartbeat(5); 
    Connection connection = cf.newConnection(); 

    channel = connection.createChannel(); 
    channel.queueDeclare("test", true, false, false, null); 
    channel.exchangeDeclare("testExchange", "direct",true); 
    channel.queueBind("test", "testExchange", "testRoutingKey"); 

    connection.addShutdownListener(new ShutdownListener() { 

     @Override 
     public void shutdownCompleted(ShutdownSignalException cause) { 
      System.out.println("test"+cause); 
     } 
    }); 

Отправка сообщения:

  channel.basicPublish("testExchange", "testRoutingKey", null,messageBodyBytes); 

Answer 1

От RabbitMQ Google

Сообщения в AMQP 0-9-1 не публикуются в очередях; они публикуются на биржах, откуда они направляются в очередь (или другую биржу) или нет. [1] basic.publish - полностью асинхронный метод протокола по дизайну: для него нет ответа , если вы не попросите его [2]. Сообщения, которые являются неопробованными, могут быть возвращены издателю , если вы определяете приемник возврата и публикуете с обязательным флагом, установленным в true. Обратите внимание, что издатель подтверждает и обязательный флаг/возврат ортогонален, а один не означает другой.

Определение возвратного прослушивателя и установка обязательного флага true была решена моя проблема. Если какое-либо сообщение не было маршрутизировано, я могу поймать их с помощью ReturnListener и добавить в мою постоянную очередь, чтобы отправить другое время, когда система становится активной.