After upgrading to 3.4.4 links hierarchy causes java.lang.OutOfMemoryError: Java heap space

Question

Hello, we recently have run into a problem when multiple users try to pull up links hierarchy for a single issue with a depth of 9 with 100 issue linked acrossed those depth's. Log has the following My question is there a setting i need to change? thanks Feb 25, 2014 3:50:19 AM org.apache.tomcat.util.http.Parameters processParameters INFO: Invalid chunk starting at byte [213] and ending at byte [220] with a value of [=Filter] ignored Note: further occurrences of Parameter errors will be logged at DEBUG level. Feb 26, 2014 6:40:32 PM org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler ["http-bio-80"] Feb 26, 2014 6:40:34 PM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Catalina CharStream.(SimpleCharStream.java:270) at org.apache.tomcat.util.http.parser.HttpParser.(HttpParser.java:226) at org.apache.catalina.connector.Response.setContentType(Response.java:804) at org.apache.catalina.connector.ResponseFacade.setContentType(ResponseFacade.java:245) at javax.servlet.ServletResponseWrapper.setContentType(ServletResponseWrapper.java:123) at com.atlassian.core.filters.encoding.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:39) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at com.atlassian.jira.web.filters.PathMatchingEncodingFilter.doFilter(PathMatchingEncodingFilter.java:45) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.atlassian.jira.startup.JiraStartupChecklistFilter.doFilter(JiraStartupChecklistFilter.java:78) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:87) at com.atlassian.jira.web.filters.JiraFirstFilter.doFilter(JiraFirstFilter.java:57) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) Exception in thread "http-bio-80-exec-1210" java.lang.OutOfMemoryError: Java heap space at org.apache.tomcat.util.http.parser.SimpleCharStream.(SimpleCharStream.java:262) at org.apache.tomcat.util.http.parser.SimpleCharStream.(SimpleCharStream.java:270) at org.apache.tomcat.util.http.parser.HttpParser.(HttpParser.java:226) at org.apache.catalina.connector.Response.setContentType(Response.java:804) at org.apache.catalina.connector.ResponseFacade.setContentType(ResponseFacade.java:245) at javax.servlet.ServletResponseWrapper.setContentType(ServletResponseWrapper.java:123) at com.atlassian.core.filters.encoding.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:39) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at com.atlassian.jira.web.filters.PathMatchingEncodingFilter.doFilter(PathMatchingEncodingFilter.java:49) at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.atlassian.jira.startup.JiraStartupChecklistFilter.doFilter(JiraStartupChecklistFilter.java:78) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:87) at com.atlassian.jira.web.filters.JiraFirstFilter.doFilter(JiraFirstFilter.java:57) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

Pbratlien · Answer

All,

the issue appears to be with a the issues linked.  A couple of our users linked parent to child back to child in other words the parent was a child of the child.  Once we cleared these up the issue resolved itself

thanks for the help

Contact Kintosoft · Answer

Downgrade please to the 3.4.2 version as the 3.4.3 version has been set private to avoid downloading. For sure, the 3.4.3 version would work worst than the 3.4.4.

The depth devels (1,2,3,5,10) are not available in the 3.4.2 version, your users have to enable the autoexpand all (unlimmited levels) option which will overload the system more than the 3.4.4 version which limits the maximum levels to 10.

Limiting too much the depth of hierarchies is difficult as other users works with depths > 10 and they requested by the autoexpand all levels at once.

I do not discard a problem with the Links Hierarchy plugin, however, in the log you posted there is nothing related to it DIRECTLY. It correspons to other process. Well, maybe your system was overhead by some processes (including Links Hierarchy) and then your JIRA crashed. So, it is not a bad idea following the @Mirceasuggestions to increase the memory and make a heap dump for further analysis.... But I would say maybe it is a good idea try to see the hierarchy again with the 3.4.4 version. If it goes out of memory then the plugin has a bug for sure, or it requires some resource consumtion autolimitation while if your users are able to see it, then the problem might be (partially, of course) in your JIRA configuration.

Mircea Vutcovici · Answer

First you should increase the Maximum Java Heap Size. It is the -Xmx parmeter that you can find the startup of JVM. I usually increase it with 30% of the current size. Make sure you have enough free phisical memory. The server must not swap and if it is a VM, the memory should not be overcommited for this VM.

After you have the JVM running you can make a Heap Dump and analize it to see which types of objects are populating the Heap. Base on this you can decide if it is a bug in code or normal usage of the application.