Uploaded image for project: 'JBoss A-MQ'
  1. JBoss A-MQ
  2. ENTMQ-2066

Excessive Number of A-MQ Consumer Objects

XMLWordPrintable

    • Hide

      1. Grab a 6.2.1 GA standalone A-MQ broker and edit it’s etc/users.properties file to add the following 2 lines:

      #joef=joef,admin,manager,viewer,Operator, Maintainer, Deployer, Auditor, Administrator, SuperUser
      joef=joef,User
      

      The above will preclude the user ‘joef’ from reading the queues.

      2. Start the broker and as user ‘admin’, create a queue called ‘TOOL.DEFAULT’. You can do this via Hawtio or JConsole.

      3. Download the attached reproducer (camel-amq-client.zip), extract its contents and edit its ../META-INF/spring/camel-context.xml file to update the failover connector’s IP address to that of your target broker.

      4. Build the reproducer using ‘mvn clean install’

      5. Run the reproducer’s client using ‘mvn camel:run’ and let it run for 2-3 minutes. You’ll note the following INFO and WARN statements being put out while the client continuously attempts to read from the queue.

      2017-01-25 21:19:14,912 [ActiveMQ Task-1] INFO  FailoverTransport              - Successfully connected to tcp://10.0.1.21:61616
      2017-01-25 21:19:14,926 [Camel (camel-1) thread #4 - JmsConsumer[TOOL.DEFAULT]] INFO  ultJmsMessageListenerContainer - Successfully refreshed JMS Connection
      2017-01-25 21:19:19,931 [Camel (camel-1) thread #12 - JmsConsumer[TOOL.DEFAULT]] WARN  ultJmsMessageListenerContainer - Setup of JMS message listener invoker failed for destination 'TOOL.DEFAULT' - trying to recover. Cause: User joef is not authorized to read from: queue://TOOL.DEFAULT
      

      You’ll also note, on JConsole or Hawtio, the number of connections being made to the broker is greater than one and the number fluctuates.

      7. Stop the broker, but do not stop the client; let it continue to run.

      8. Edit the broker’s etc/users.properties file so that the two previous lines are now as such:

      joef=joef,admin,manager,viewer,Operator, Maintainer, Deployer, Auditor, Administrator, SuperUser
      #joef=joef,User
      

      This will now give the ‘joef’ user access rights to the queue.

      9. Start the broker back up.

      What you’ll note is a large number of redundant consumer objects are created on the broker as soon as it starts back up. You can view this using Hawtio or JConsole. Because the route has concurrentConsumers=10, there should only be 10 consumer objects and only one connection, but you’ll note many more registered on the console.

      If you inspect the threads on the client, you’ll note the following:

      • multiple “ActiveMQ Transport” threads
      • multiple “ActiveMQ InactivityMonitor Worker” threads.
      • 11 Camel (camel-1) thread #<number> - JmsConsumer threads

      The number of overall threads on the client does not increase over time.

      If you then stop and restart the client, everything goes back to normal.

      • one “ActiveMQ Transport” thread
      • one “ActiveMQ InactivityMonitor Worker” thread.
      • 10 Camel (camel-1) thread #<number> - JmsConsumer threads
      Show
      1. Grab a 6.2.1 GA standalone A-MQ broker and edit it’s etc/users.properties file to add the following 2 lines: #joef=joef,admin,manager,viewer,Operator, Maintainer, Deployer, Auditor, Administrator, SuperUser joef=joef,User The above will preclude the user ‘joef’ from reading the queues. 2. Start the broker and as user ‘admin’, create a queue called ‘TOOL.DEFAULT’. You can do this via Hawtio or JConsole. 3. Download the attached reproducer (camel-amq-client.zip), extract its contents and edit its ../META-INF/spring/camel-context.xml file to update the failover connector’s IP address to that of your target broker. 4. Build the reproducer using ‘mvn clean install’ 5. Run the reproducer’s client using ‘mvn camel:run’ and let it run for 2-3 minutes. You’ll note the following INFO and WARN statements being put out while the client continuously attempts to read from the queue. 2017-01-25 21:19:14,912 [ActiveMQ Task-1] INFO FailoverTransport - Successfully connected to tcp: //10.0.1.21:61616 2017-01-25 21:19:14,926 [Camel (camel-1) thread #4 - JmsConsumer[TOOL.DEFAULT]] INFO ultJmsMessageListenerContainer - Successfully refreshed JMS Connection 2017-01-25 21:19:19,931 [Camel (camel-1) thread #12 - JmsConsumer[TOOL.DEFAULT]] WARN ultJmsMessageListenerContainer - Setup of JMS message listener invoker failed for destination 'TOOL.DEFAULT' - trying to recover. Cause: User joef is not authorized to read from: queue: //TOOL.DEFAULT You’ll also note, on JConsole or Hawtio, the number of connections being made to the broker is greater than one and the number fluctuates. 7. Stop the broker, but do not stop the client; let it continue to run. 8. Edit the broker’s etc/users.properties file so that the two previous lines are now as such: joef=joef,admin,manager,viewer,Operator, Maintainer, Deployer, Auditor, Administrator, SuperUser #joef=joef,User This will now give the ‘joef’ user access rights to the queue. 9. Start the broker back up. What you’ll note is a large number of redundant consumer objects are created on the broker as soon as it starts back up. You can view this using Hawtio or JConsole. Because the route has concurrentConsumers=10, there should only be 10 consumer objects and only one connection, but you’ll note many more registered on the console. If you inspect the threads on the client, you’ll note the following: multiple “ActiveMQ Transport” threads multiple “ActiveMQ InactivityMonitor Worker” threads. 11 Camel (camel-1) thread #<number> - JmsConsumer threads The number of overall threads on the client does not increase over time. If you then stop and restart the client, everything goes back to normal. one “ActiveMQ Transport” thread one “ActiveMQ InactivityMonitor Worker” thread. 10 Camel (camel-1) thread #<number> - JmsConsumer threads

      Insufficient access control settings on the broker result in a Camel route creating an excessive number of consumer objects on the broker once the access control settings are properly set.

        1. blueprint.xml
          2 kB
          Travis North
        2. CamelRoute.png
          78 kB
          Travis North
        3. TwoConnectionsWithInvalidUserId.png
          37 kB
          Travis North
        4. TwoConnectionsWithValidUserId.png
          65 kB
          Travis North

              gtully@redhat.com Gary Tully
              Argo_Integration Travis North (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: