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

RabbitConsumer.stop() doesn't stop underlying AutorecoveringConnection obtained from supplied ConnectionFactory

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.17.1
    • Fix Version/s: 2.17.2, 2.18.0
    • Component/s: camel-rabbitmq
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      If I have a ConnectionFactory defined as:

      ConnectionFactory connectionFactory = new ConnectionFactory();
      connectionFactory.setAutomaticRecoveryEnabled(true);
      connectionFactory.setUsername(username);
      connectionFactory.setPassword(password);
      

      And a Camel route defined like:

      rabbitmq://localhost:5672/MyExchange?connectionFactory=#connectionFactory&exchangeType=direct&queue=MyQueue&routingKey=MyRoutingKey
      

      Performing these steps:

      • Start my application and it connects to Rabbit and consumes messages
      • Shutdown the RabbbitMQ server
      • Shutdown my Camel application

      The application doesn't stop fully because the automatic recovery mechanism has background threads running. It carries on indefinately logging messages like:

      	at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:106)
      	at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:102)
      	at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:350)
      	at com.rabbitmq.client.impl.recovery.RecoveryAwareAMQConnectionFactory.newConnection(RecoveryAwareAMQConnectionFactory.java:37)
      	at com.rabbitmq.client.impl.recovery.AutorecoveringConnection.recoverConnection(AutorecoveringConnection.java:476)
      	at com.rabbitmq.client.impl.recovery.AutorecoveringConnection.beginAutomaticRecovery(AutorecoveringConnection.java:444)
      	at com.rabbitmq.client.impl.recovery.AutorecoveringConnection.access$000(AutorecoveringConnection.java:53)
      	at com.rabbitmq.client.impl.recovery.AutorecoveringConnection$1.shutdownCompleted(AutorecoveringConnection.java:383)
      	at com.rabbitmq.client.impl.ShutdownNotifierComponent.notifyListeners(ShutdownNotifierComponent.java:75)
      	at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:578)
      

      Looking at org.apache.camel.component.rabbitmq.RabbitConsumer.stop()

          public void stop() throws IOException, TimeoutException {
              stopping = true;
              if (channel == null) {
                  return;
              }
              channel.basicCancel(tag);
              try {
                  channel.close();
              } catch (TimeoutException e) {
                  log.error("Timeout occured");
                  throw e;
              }
          }
      

      The calls to channel.basicCancel(tag) and channel.close() both throw com.rabbitmq.client.AlreadyClosedException when the server has closed the connection which stops the automatic recovery thread from being halted. Checking whether the channel is open before the calls to channel.basicCancel(tag) and channel.close() seems to fix the issue.

          public void stop() throws IOException, TimeoutException {
              stopping = true;
              if (channel == null) {
                  return;
              }
              if (tag != null && isChannelOpen()) {
                  channel.basicCancel(tag);
              }
              try {
                  if (isChannelOpen()) {
                      channel.close();
                  }
              } catch (TimeoutException e) {
                  log.error("Timeout occured");
                  throw e;
              }
          }
      

      I'll submit a PR later

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                davsclaus Claus Ibsen
                Reporter:
                daknin Darrell King
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: