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

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

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

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?

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

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.

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

Looking for anyone who made the switch to Data Center

The Jira Marketing team is putting together an ebook on migrating to Data Center. We're looking for pro tips on how you staffed your project team and organized your Proof of Concept. Share yo...

39 views 0 2
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you