Uploaded image for project: 'Camel'
  1. Camel
  2. CAMEL-11791

RabbitMQ Producer/Consumer does not recover if exchange/queue is deleted manually

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.19.2
    • Fix Version/s: 2.19.4, 2.20.0
    • Component/s: camel-rabbitmq
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      While trying different recovering scenarios with camel-rabbitmq we tried to delete the exchange where the producer was sending RabbitMQ messages to.

      We observed that the exchange was never recreated again as well as no new channel were created in the channel pool. Every time a channel was used to send a non-existent exchange, the channel was closed and we got a log saying "Got a closed channel from the pool". Once it ran out of channels in the pool, we keep getting the same exception when a new message tries to be sent to the exchange:

      Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
      at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1174) ~[commons-pool-1.6.jar:1.6]
      

      We are using a InOnly producer and the options we are using are:

      rabbitmq://somehose:someport/some_exchange?username=SomeApp&password=SomeApp&skipQueueDeclare=true&exchangeType=headers&automaticRecoveryEnabled=true&topologyRecoveryEnabled=true
      

      It seems the code never catches a Exception thrown by channel.basicPublish(...) in RabbitMQMessagePublisher. Maybe we could catch if the issue is that the exchange got deleted and run the exchange declaration again?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                davsclaus Claus Ibsen
                Reporter:
                hveiga Hector Veiga
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: