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

Pbratlien February 25, 2014

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.<init>(SimpleCharStream.java:270)

at org.apache.tomcat.util.http.parser.HttpParser.<init>(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.<init>(SimpleCharStream.java:262)

at org.apache.tomcat.util.http.parser.SimpleCharStream.<init>(SimpleCharStream.java:270)

at org.apache.tomcat.util.http.parser.HttpParser.<init>(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)

5 answers

1 vote
Pbratlien March 26, 2014

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

0 votes
Pablo Beltran
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 26, 2014

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.

0 votes
Mircea Vutcovici February 25, 2014

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.

0 votes
Pbratlien February 25, 2014

Q1) 3.4.3 appeared to have the same problems but we rolled back and will let you know

Q2) Not seeing the problem with EPICs but are user base doesn't have that large of epics (ie not as many issues linked to epics)

Q3) Autoexpand set to 10 and the user set was 5 that i know of but we do have 1,000+ users so it could be more.

thanks

0 votes
Pablo Beltran
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 25, 2014

Some few questions:

Q1) What version were you using before 3.4.4? Could you see the same issue with and older version?

Q2) Is the herarchy having Epics?

Q3) The 3.4.4 (and 3.4.3) version supports a new feature to auto expand hierarchies up to 10 depth levels. Then, I guess some of them are setting to 10 the autoexpand depth option in order to view the full hierarchy? how many concurrent users are doing that approximatelly?

Suggest an answer

Log in or Sign up to answer