Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-194

Broker instance tmp folder grows big and does not clean itself

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • A-MQ 7.0.0.GA
    • None
    • None
    • None
    • AMQ 7.0.2 sprint 1

    Description

      It seems like some autoclean-up of hawtio and web-related-stuff (artemis-plugin-war) directories are not being removed after some time on average broker usage.
      I have been running ER2 for ~14 days and I see that 

      ${broker_instance}/tmp

      folder has 3.3GB and will most probably grow even bigger.
      Mostly consisting of two folders (being created on each new run and not removing the old one/s?).

      36M	/opt/jboss-amq-7-i0/tmp/jetty-localhost-8161-hawtio-web.war-_hawtio-any-6699908872658644910.dir
808K	/opt/jboss-amq-7-i0/tmp/jetty-localhost-8161-artemis-plugin.war-_artemis-plugin-any-4427642750879659293.dir

      Please see the attached log for more details. Also, I am using almost "default" broker.xml. Attached as well. Could you advice what to set to prevent this behavior if possible?
      I did not find relevant answer in current 1.2.0 upstream documentation.

      Attachments

        1. du-random-user-artemis.log
          34 kB
        2. du-one-user-artemis.log
          13 kB
        3. du-artemis.log
          19 kB
        4. broker.xml
          4 kB

        Issue Links

          is blocked by

          Task - Represents a small unit of work that is not end-user facing. ENTMQBR-386 Release 7.0.0.ER8 with Hand Off document

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is cloned by

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. ENTMQBR-764 Make artemis service a blocking instead non-blocking operation

          • Minor - To be worked after urgent, high, and medium priorities are resolved. This term is chosen when the severity of the issue is low, or the complexity or effort to correct it may be higher, relatively speaking. For low priority issues, known workarounds exist or are not needed due to the trivial effort needed to address the issue.
          • New
          is related to

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. ENTMQBR-764 Make artemis service a blocking instead non-blocking operation

          • Minor - To be worked after urgent, high, and medium priorities are resolved. This term is chosen when the severity of the issue is low, or the complexity or effort to correct it may be higher, relatively speaking. For low priority issues, known workarounds exist or are not needed due to the trivial effort needed to address the issue.
          • New

          ARTEMIS-619 Loading...

          relates to

          Bug - A problem that impairs or prevents the functions of the product. ENTMQBR-4 WARs are not being removed after broker stops, polluting broker tmp directory

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. ENTMQBR-4 WARs are not being removed after broker stops, polluting broker tmp directory

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              rhn-support-jbertram Justin Bertram
              mtoth@redhat.com Michal Toth
              Dmitrii Puzikov Dmitrii Puzikov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: