Performance degradation and high response time on Jira Data Center application due to changes in velocity.properties
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Performance degradation and high response time on Jira Data Center application due to changes in velocity.properties
Velocity is a server-side templating language used by Jira to render page content. Velocity allows Java objects to be called alongside standard HTML.
So while rendering contents on the Jira page and its layout, we use these templates to get the HTML format as well as the text and other contents
Now, this is where we see threads are slow. HOWEVER, we do not see threads being hung. They are moving slow, which means that the application is not completely unresponsive.
Diagnosis
If you could collect thread dumps at the time of the issue, You will notice that the below threads are very slow in pace.
Most of the HTTP executable threads are waiting in the below condition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
"https-jsse-nio-7010-exec-36 url:/sr/jira.issuev.../SearchRequest.xml username:XXXXX" #3148 daemon prio=5 os_prio=0 cpu=232828.19ms elapsed=9696.05s tid=0x00007f58080b0800 nid=0x1618 waiting for monitor entry [0x00007f575c51e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:571)
- waiting to lock <0x00000006aae019f8> (a org.apache.velocity.runtime.VelocimacroFactory)
at org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:1562)
at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:199)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
at org.apache.velocity.Template.merge(Template.java:328)
at org.apache.velocity.Template.merge(Template.java:235)
at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:381)
at com.atlassian.velocity.DefaultVelocityManager.writeEncodedBodyImpl(DefaultVelocityManager.java:117)
at com.atlassian.velocity.DefaultVelocityManager.writeEncodedBody(DefaultVelocityManager.java:97)
at com.atlassian.jira.template.velocity.DefaultVelocityTemplatingEngine$DefaultRenderRequest.toWriterImpl(DefaultVelocityTemplatingEngine.java:122)
at com.atlassian.jira.template.velocity.DefaultVelocityTemplatingEngine$DefaultRenderRequest.asHtml(DefaultVelocityTemplatingEngine.java:113)
at com.atlassian.jira.plugin.AbstractJiraModuleDescriptor.writeHtml(AbstractJiraModuleDescriptor.java:127)
at com.atlassian.jira.plugin.AbstractJiraModuleDescriptor.getHtml(AbstractJiraModuleDescriptor.java:106)
at com.atlassian.jira.issue.views.IssueXMLView.getBody(IssueXMLView.java:177)
You notice that this thread is waiting to lock 0x00000006aae019f8 which is held by exec-28
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
"https-jsse-nio-7010-exec-28 url:/rest/greenhopp...issue/details.json username:XXXXX" #3140 daemon prio=5 os_prio=0 cpu=247513.52ms elapsed=9700.25s tid=0x00007f58080aa800 nid=0x160b runnable [0x00007f5761b55000]
java.lang.Thread.State: RUNNABLE
at org.apache.velocity.runtime.parser.ParserTokenManager.getNextToken(ParserTokenManager.java:4237)
at org.apache.velocity.runtime.parser.Parser.jj_scan_token(Parser.java:3327)
at org.apache.velocity.runtime.parser.Parser.jj_3_7(Parser.java:2875)
at org.apache.velocity.runtime.parser.Parser.jj_2_7(Parser.java:2560)
at org.apache.velocity.runtime.parser.Parser.Reference(Parser.java:1317)
at org.apache.velocity.runtime.parser.Parser.DirectiveArg(Parser.java:610)
at org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:787)
at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:373)
at org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:888)
at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:373)
at org.apache.velocity.runtime.parser.Parser.process(Parser.java:311)
at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:105)
at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1130)
at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1085)
at org.apache.velocity.Template.process(Template.java:124)
at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446)
at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354)
at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1400)
at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1379)
at org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:625)
- locked <0x00000006aae019f8> (a org.apache.velocity.runtime.VelocimacroFactory)Cause
In the velocity.properties file, the resource loader cache was disabled. This could end up slowing up parsing velocity templates.
1
class.resource.loader.cache=falseSolution
Make sure to enable the resource loader cache in the velocity.properties file. Default Location of velocity.properties : <jira-installation-directory>/atlassian-jira/WEB-INF/classes/
1
class.resource.loader.cache=trueWas this helpful?