when on 32-bit Sun JVMs giving JIRA too much heap can cause bogus Out of Memory Exceptions within Lucene

XMLWordPrintable

    • 4.01
    • 1
    • Severity 3 - Minor
    • Hide
      Atlassian Update – 06 November 2019

      Hi everyone,

      After reviewing the overall customer interest and impact of this bug report we have decided to close this issue down. Our analysis has shown that over time this issue hasn't collected a significant number of votes, watchers, comments, or support cases from customers and therefore has remained very low on our priority list. Given these findings we can conclude it will not be fixed in the foreseeable future and wish to be transparent about our priorities by closing it as Timed Out.

      Although we're aware this issue may be still important to those of you who were involved in the initial conversations around it, we want to be clear by managing your expectations regarding the likelihood of a fix for it. The Jira team do their best to prioritise the issues that have high and critical impact with broad pervasiveness reflected in series of different factors. You can learn more about this by reading our Bug Fixing Policy.

      To see what the Jira team is currently working on and has recently delivered see the following dashboards:

      We understand that hearing a decision like this can be disappointing, but we hope you'll appreciate our transparent approach to product priorities and communications. We will continue to watch this issue for further updates, so please feel free to share any thoughts in the comments.

      Thank you,

      Pawel Drygas,

      Jira Server Bugmaster

      Show
      Atlassian Update – 06 November 2019 Hi everyone, After reviewing the overall customer interest and impact of this bug report we have decided to close this issue down. Our analysis has shown that over time this issue hasn't collected a significant number of votes, watchers, comments, or support cases from customers and therefore has remained very low on our priority list. Given these findings we can conclude it will not be fixed in the foreseeable future and wish to be transparent about our priorities by closing it as Timed Out . Although we're aware this issue may be still important to those of you who were involved in the initial conversations around it, we want to be clear by managing your expectations regarding the likelihood of a fix for it. The Jira team do their best to prioritise the issues that have high and critical impact with broad pervasiveness reflected in series of different factors. You can learn more about this by reading our Bug Fixing Policy . To see what the Jira team is currently working on and has recently delivered see the following dashboards: Jira Server and Data Center: Recently resolved issues Jira Server and Data Center: Current work and future plans Jira Server and Data Center: Bug Fix Board We understand that hearing a decision like this can be disappointing, but we hope you'll appreciate our transparent approach to product priorities and communications. We will continue to watch this issue for further updates, so please feel free to share any thoughts in the comments. Thank you, Pawel Drygas, Jira Server Bugmaster

      If you give JIRA "too much" heap (e.g. 2 or 3 GB) then you may get a stack trace that looks like:

      HTTP Status 404 - Could not execute action [ViewIssue]:OutOfMemoryError likely caused by the Sun VM Bug described in https://issues.apache.org/jira/browse/LUCENE-1566; try calling FSDirectory.setReadChunkSize with a a value smaller than the current chunk size (104857600)<p><small><small><pre>java.lang.OutOfMemoryError: OutOfMemoryError likely caused by the Sun VM Bug described in https://issues.apache.org/jira/browse/LUCENE-1566; try calling FSDirectory.setReadChunkSize with a a value smaller than the current chunk size (104857600) at

      If you look at LUCENE-1566 you can see that the actual problem is a bug in Sun's 32-bit JVMs that Lucene trips over. In Lucene 2.9 (which is in JIRA 4.1) they have added a workaround the handles most heap sizes but if you go too large (say 3GB) then you still trip over the problem.

      From what I can tell this could happen on any version of JIRA. Since we haven't had users complaining then it must not be a very common occurence. We tripped over it on SAC mostly by accident.

      I think trying to have JIRA handle this would add Yet Another Configuration Knob for what appears to be a very rare case. As Chris pointed out, it isn't even clear what kind of instance you would have that would require that much heap and whether JIRA works at all with instances that large.

      It seems like a better solution would to add a SystemEnvironmentCheck that looks for this scenario and gives the user a warning and a link to a knowledge base article explaining the situation.

            Assignee:
            Unassigned
            Reporter:
            Justus Pendleton (Inactive)
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: