• We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      The StepBoard contained in the request maintains a List of Issue objects (the result of a search, so DocumentIssueImpl instances in practice). This list can get very large if the issues happen to contain any large fields such as environment or description. On http://jira.atlassian.com we have seen OutOfMemoryError heap dumps that have contained 300MB of StepBoard instance retained memory - and 600MB of Document instance retained memory (which is mostly stack-local, we haven't worked out what stack frames own this yet).

      As we are not familiar with the code, we aren't sure why this is implemented in this way, but it is a potentially unbound resource use that does not scale well at all. Please consider limiting the results via a PagerFilter.

            [JSWSERVER-406] High memory usage of request local StepBoard

            In 2.5M1 EAP release the Administration -> GreenHopper page has a typo:

            "Task Board ressources" should be "Task Board resources"

            Deleted Account (Inactive) added a comment - In 2.5M1 EAP release the Administration -> GreenHopper page has a typo: "Task Board ressources" should be "Task Board resources"

            AntonA added a comment -

            Hi,

            Thanks for the update. The solution sounds good.

            Cheers,
            Anton

            AntonA added a comment - Hi, Thanks for the update. The solution sounds good. Cheers, Anton

            JC added a comment - - edited

            OK here is what we are going to do:

            The concept of a task board is not meant to be used with a very large set of issues. If you have a large number of issues in a version, you want to use a context to reduce it to a number that is manageable by a human being. Anyhow I think all will agree that we are loosing the purpose of a TaskBoard if too much Issues are displayed.

            We are going to add a capability in the TaskBoard to display a message asking to configure (something like a search with to many results asking you to precise your search) a filter when the number of these issues is exceeding a configurable MAX.

            First there will be an option to turn on the locking of the TaskBoard, defaulting to false to preserve the current behavior. When turned on, the user will specify the maximum number of issues for which a TaskBoard can be displayed.

            From a technical perspective, the MAX number to manage will behave like the following:

            • -1 => Lock task Board
            • 0 => No maximum, behave the same as before
            • N => Do not display issues and ask for filtering if more then N

            JC added a comment - - edited OK here is what we are going to do: The concept of a task board is not meant to be used with a very large set of issues. If you have a large number of issues in a version, you want to use a context to reduce it to a number that is manageable by a human being. Anyhow I think all will agree that we are loosing the purpose of a TaskBoard if too much Issues are displayed. We are going to add a capability in the TaskBoard to display a message asking to configure (something like a search with to many results asking you to precise your search) a filter when the number of these issues is exceeding a configurable MAX. First there will be an option to turn on the locking of the TaskBoard, defaulting to false to preserve the current behavior. When turned on, the user will specify the maximum number of issues for which a TaskBoard can be displayed. From a technical perspective, the MAX number to manage will behave like the following: -1 => Lock task Board 0 => No maximum, behave the same as before N => Do not display issues and ask for filtering if more then N

            Hi JC,

            Unfortunately the OOMEs do not appear to be specifically related to the Test project, and we are removing the plugin from JAC for the moment (we will still be using internally on another instance). It is very good to hear about performance improvements in 2.4.

            Our problem stems from a combination of the slowness of the StepBoard request and the spidering of those links. We have had up to 75 concurrent request processes in the system at a time (at the time of the OOME).

            We do not have the time or resources to do a more exhaustive analysis of the resource consumption of the whole plugin, but if we do notice anything we will let you know.

            cheers,
            jed.

            Jed Wesley-Smith added a comment - Hi JC, Unfortunately the OOMEs do not appear to be specifically related to the Test project, and we are removing the plugin from JAC for the moment (we will still be using internally on another instance). It is very good to hear about performance improvements in 2.4. Our problem stems from a combination of the slowness of the StepBoard request and the spidering of those links. We have had up to 75 concurrent request processes in the system at a time (at the time of the OOME). We do not have the time or resources to do a more exhaustive analysis of the resource consumption of the whole plugin, but if we do notice anything we will let you know. cheers, jed.

            Please see GHS-409 for a related issue about hiding the StepBoard links from spiders.

            Jed Wesley-Smith added a comment - Please see GHS-409 for a related issue about hiding the StepBoard links from spiders.

            JC added a comment -

            Hi Jed,

            Yeah, the TaskBoard was not really meant to support 2000 issues in a single version.
            Removing your A Test Project from the "GreenHopper enable" list should prevent you from the OutOfMemoryError heap.

            We should be able to use the PageFilter to increase the scalability. We will look into it first thing in release 2.5

            If you have any inputs on where GreenHopper might also be burning too much resources please again let us know so we can adjust.

            Cheers,

            JC added a comment - Hi Jed, Yeah, the TaskBoard was not really meant to support 2000 issues in a single version. Removing your A Test Project from the "GreenHopper enable" list should prevent you from the OutOfMemoryError heap. We should be able to use the PageFilter to increase the scalability. We will look into it first thing in release 2.5 If you have any inputs on where GreenHopper might also be burning too much resources please again let us know so we can adjust. Cheers,

            JC added a comment - - edited

            Hi Jed,

            I will look into it.

            As for now my advise would be to remove your test project from using GreenHopper
            You can do so from your JIRA - Administration -Global Settings - GreenHopper - Applicable Context

            Also if that can help, Friday May 2nd we are releasing GreenHopper 2.4, we have greatly improved the performance.

            Cheers,

            JC added a comment - - edited Hi Jed, I will look into it. As for now my advise would be to remove your test project from using GreenHopper You can do so from your JIRA - Administration -Global Settings - GreenHopper - Applicable Context Also if that can help, Friday May 2nd we are releasing GreenHopper 2.4, we have greatly improved the performance. Cheers,

              Unassigned Unassigned
              jwesleysmith Jed Wesley-Smith
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: