Объявление 2-й очереди с обменом по умолчанию приводит к ошибке

Question

Spring Boot 1.5.15

Когда я объявляю одну очередь, эта очередь объявляется и отправка / получение работают нормально. Если я добавляю вторую (и последующие) очереди, регистрируется ошибка, очереди повторно объявляются 5 раз, и, наконец, приложение не запускается.

Конфигурация Spring Boot RabbitMQ:

    @Configuration
    public class RabbitConfig implements RabbitListenerConfigurer {

        @Autowired
        private ObjectMapper mapper;

        @Bean
        Queue crmAppealQueue(@Value("${app.queues.portalAppeal}") String queueName) {
            return new Queue(queueName, false);
        }

        @Bean
        Queue portalUserQueue(@Value("${app.queues.portalUser}") String queueName) {
            return new Queue(queueName, false);
        }

        @Override
        public void configureRabbitListeners(RabbitListenerEndpointRegistrar registrar) {
            registrar.setMessageHandlerMethodFactory(messageHandlerMethodFactory());
        }

        @Bean
        MessageHandlerMethodFactory messageHandlerMethodFactory() {
            DefaultMessageHandlerMethodFactory messageHandlerMethodFactory = new DefaultMessageHandlerMethodFactory();
            messageHandlerMethodFactory.setMessageConverter(consumerJackson2MessageConverter());
            return messageHandlerMethodFactory;
        }

        @Bean
        public MappingJackson2MessageConverter consumerJackson2MessageConverter() {
            return new MappingJackson2MessageConverter();
        }

        @Bean
        public RabbitTemplate rabbitTemplate(final ConnectionFactory connectionFactory) {
            final RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory);
            rabbitTemplate.setMessageConverter(producerJackson2MessageConverter());
            return rabbitTemplate;
        }

        @Bean
        public Jackson2JsonMessageConverter producerJackson2MessageConverter() {
            return new Jackson2JsonMessageConverter(mapper);
        }
}

Журналы с ошибками:

2018-29-08 15:04:52,075  INFO (RabbitAdmin.java:566) - Auto-declaring a non-durable, auto-delete, or exclusive Queue (portal.appeal) durable:false, auto-delete:false, exclusive:false. It will be redeclared if the broker stops and is restarted while the connection factory is alive, but all messages will be lost.
2018-29-08 15:04:52,075  INFO (RabbitAdmin.java:566) - Auto-declaring a non-durable, auto-delete, or exclusive Queue (portal.user) durable:false, auto-delete:false, exclusive:false. It will be redeclared if the broker stops and is restarted while the connection factory is alive, but all messages will be lost.
2018-29-08 15:04:52,122 ERROR (CachingConnectionFactory.java:1327) - Channel shutdown: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - inequivalent arg 'durable' for queue 'portal.user' in vhost '/': received 'false' but current is 'true', class-id=50, method-id=10)

Если закомментировано одно объявление очереди, то в журнале указывается, что объявлена ​​только одна очередь, а приложение продолжает загружаться (то есть другая очередь не объявлена ​​в другом месте)

2018-29-08 17:21:49,435  INFO (AbstractConnectionFactory.java:379) - Created new connection: rabbitConnectionFactory#74ba4614:0/SimpleConnection@2a6c087d [delegate=amqp://precrm@192.168.82.177:5672/, localPort= 63501]
2018-29-08 17:21:49,435  INFO (RabbitAdmin.java:566) - Auto-declaring a non-durable, auto-delete, or exclusive Queue (portal.appeal) durable:false, auto-delete:false, exclusive:false. It will be redeclared if the broker stops and is restarted while the connection factory is alive, but all messages will be lost.
2018-29-08 17:21:49,529  INFO (StartupInfoLogger.java:57) - Started PortalAppealMessageHandlerTest in 5.317 seconds (JVM running for 6.599)

Answer 1

Хорошо, это было глупо (вполне ожидаемо).

Я предполагал, что очередь создается с нуля каждый раз, когда она объявляется, чего не было, учитывая мою конфигурацию.

На самом деле он существовал с другим аргументом долговечности - именно то, о чем мне пыталась сообщить сообщение об ошибке.

Решение: я удалил его, используя AmqAdmin.deleteQueue()