Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-6052

Jolokia creates disproportionate load on JVM heap with large queries

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • fuse-6.x-GA
    • jboss-fuse-6.2.1
    • Hawtio
    • None
    • % %
    • Hide

      These reproduction steps use JMS consumers, because that was the problem scenario reported by the customer. However, I don't have any particular reason to think that the problem is limited to JMS-related queries.

      1. Install ActiveMQ 6.2.1 Rollup 2
      2. Run an application that creates 100 concurrent consumers on a particular queue (some simple code is attached)
      3. Get a heap histogram (e.g., jmap -histo)
      4. Execute this Jolokia request:

      http://localhost:8181/jolokia/read/org.apache.activemq:type=Broker,brokerName=root,destinationType=Queue,destinationName=*

      5. Get a heap histogram again
      6. Repeat steps 4 and 5, and note how the numbers of instances of JSONObject increase, along with the total heap usage.

      Show
      These reproduction steps use JMS consumers, because that was the problem scenario reported by the customer. However, I don't have any particular reason to think that the problem is limited to JMS-related queries. 1. Install ActiveMQ 6.2.1 Rollup 2 2. Run an application that creates 100 concurrent consumers on a particular queue (some simple code is attached) 3. Get a heap histogram (e.g., jmap -histo) 4. Execute this Jolokia request: http://localhost:8181/jolokia/read/org.apache.activemq:type=Broker,brokerName=root,destinationType=Queue,destinationName=* 5. Get a heap histogram again 6. Repeat steps 4 and 5, and note how the numbers of instances of JSONObject increase, along with the total heap usage.

      When executing a Jolokia query over HTTP, that returns a signficant amount of objects, a great many instances of org.json.simple.JSONObject are created in the heap, along with all their supporting data. A query that returns 100 records, for example, might create 10 000 instances, and 20Mb of heap.

      This heap is eventually reclaimed, but the use of Jolokia to return substantial numbers of objects places a severe burden on the GC, leading to high CPU usage and associated inefficiency.

      While it is natural of Java application to create objects that need to be reclaimed by GC, the problem here is that the number of objects created is massively disproportionate to amount of data returned by the query.

        2. hawtio-web-1.4.redhat-621117.war
          11.23 MB
          Paolo Antinori

              pantinor@redhat.com Paolo Antinori
              rhn-support-kboone Kevin Boone
              Pavel Macik Pavel Macik
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: