ActiveMQ
  1. ActiveMQ
  2. AMQ-3573

Hardcoded defaults for systemUsage not suitable for out of the box

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.5.1
    • Fix Version/s: 5.6.0
    • Component/s: Broker
    • Patch Info:
      Patch Available

      Description

      Right now the default activemq.xml has the entire <systemUsage> section commented out. If commented, then the default systemUsage as defined in BrokerService.getSystemUsage() applies and uses these limits:

      memoryLimit 64 MB
      storeLimit: 10 GB
      tempLimit: 100 GB

      I don't think these are good default values as in the worst case the broker may use 110 GB of disk space. Many runtime environments will not have that much disk space and are therefore in danger of running out of disk space completely.
      IMHO some more sensitive defaults would be

      memoryLimit 64 MB
      storeLimit: 1 GB
      tempLimit: 1 GB

      to prevent the broker from using too much disk space by default.
      I believe most users of ActiveMQ are unaware of these defaults and probably don't expect the broker to use up to 110 GB of their disk.

      If anyone really needs large store and temp limit, they should explicitly configure for it.

      1. AMQ-3573.patch
        2 kB
        Torsten Mielke

        Issue Links

          Activity

          Hide
          Rob Davies added a comment -

          For https://issues.apache.org/jira/browse/AMQ-3573 In junit tests - fixed null pointer if the directory doesn't exist
          Subversion: Committed revision 1327388.

          Show
          Rob Davies added a comment - For https://issues.apache.org/jira/browse/AMQ-3573 In junit tests - fixed null pointer if the directory doesn't exist Subversion: Committed revision 1327388.
          Hide
          Rob Davies added a comment -

          In junit tests - fixed warning messages can be generated for not enough disk space if the directory doesn't exist
          Subversion: Committed revision 1327379.

          Show
          Rob Davies added a comment - In junit tests - fixed warning messages can be generated for not enough disk space if the directory doesn't exist Subversion: Committed revision 1327379.
          Hide
          Timothy Bish added a comment -

          Applied fix to fix failing tests in Eclipse

          Show
          Timothy Bish added a comment - Applied fix to fix failing tests in Eclipse
          Hide
          Timothy Bish added a comment -

          The fix breaks the unit tests in Eclipse and other tools where the temp dir value is not set as an Absolute path.

          adding the following after the tmpDir null check resolves this.

                      if (!tmpDir.isAbsolute()) {
                          tmpDir = new File(tmpDirPath);
                      }
          
          Show
          Timothy Bish added a comment - The fix breaks the unit tests in Eclipse and other tools where the temp dir value is not set as an Absolute path. adding the following after the tmpDir null check resolves this. if (!tmpDir.isAbsolute()) { tmpDir = new File(tmpDirPath); }
          Hide
          Rob Davies added a comment -

          Added warning and error messages is SystemUsage values cannot be met by the system.
          Changed defaults to:
          64mb for memory
          50GB for temp store
          100GB for store
          The GB value was being incorrectly calculated
          resolved by SVN revision 1235261

          Show
          Rob Davies added a comment - Added warning and error messages is SystemUsage values cannot be met by the system. Changed defaults to: 64mb for memory 50GB for temp store 100GB for store The GB value was being incorrectly calculated resolved by SVN revision 1235261
          Hide
          Claus Ibsen added a comment -

          Isn't there an API in JDK6+ now that you can ask for disk space?

          Show
          Claus Ibsen added a comment - Isn't there an API in JDK6+ now that you can ask for disk space?
          Hide
          Torsten Mielke added a comment - - edited

          Thanks for your input Gary.
          I have repeatedly seen companies deploying ActiveMQ in production where the underlying disk had only 10-30 GB of free space left.
          Just this week I found a company that deployed ActiveMQ with almost default settings (commented <systemUsage> in ActiveMQ) and they only had 6 GB of hard disk space available.
          I believe this happens fairly often.

          I can see that the limits I proposed may seem a bit low but assuming there will be up to 110GB disk space available by default may be too much?
          Also, the default systemUsage will not be apparent from looking at the configuration (see AMQ-3574). So I presume most users of ActiveMQ are unaware of these high default limits.

          Show
          Torsten Mielke added a comment - - edited Thanks for your input Gary. I have repeatedly seen companies deploying ActiveMQ in production where the underlying disk had only 10-30 GB of free space left. Just this week I found a company that deployed ActiveMQ with almost default settings (commented <systemUsage> in ActiveMQ) and they only had 6 GB of hard disk space available. I believe this happens fairly often. I can see that the limits I proposed may seem a bit low but assuming there will be up to 110GB disk space available by default may be too much? Also, the default systemUsage will not be apparent from looking at the configuration (see AMQ-3574 ). So I presume most users of ActiveMQ are unaware of these high default limits.
          Hide
          Gary Tully added a comment -

          not sure I agree. Large disks are the norm and I think it is better to have the broker spool to disk for as long as it can rather than block pending some arbitrary small limit. I guess making small limits would make users more aware of them, but with the existing values most users can simply ignore them.

          Show
          Gary Tully added a comment - not sure I agree. Large disks are the norm and I think it is better to have the broker spool to disk for as long as it can rather than block pending some arbitrary small limit. I guess making small limits would make users more aware of them, but with the existing values most users can simply ignore them.
          Hide
          Torsten Mielke added a comment -

          Attaching a possible patch.

          Show
          Torsten Mielke added a comment - Attaching a possible patch.
          Hide
          Torsten Mielke added a comment -

          Attaching a possible patch.

          Show
          Torsten Mielke added a comment - Attaching a possible patch.

            People

            • Assignee:
              Rob Davies
              Reporter:
              Torsten Mielke
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development