jira 10.3.4 keep oom when running a period time

Question

jira version: 10.3.4

jira jvm settings: -Xms5120m -Xmx5120m

jdk version: java17

jira seems not to free memory, jvm usage go higher and higher , and finally went

OutOfMemoryError, is there a memory leak in v10.3.4?

here is the application log:

11-Sep-2025 16:06:30.867 SEVERE [http-nio-8082-exec-1] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Failed to complete processing of a request

java.lang.OutOfMemoryError: Java heap space

at com.opensymphony.module.sitemesh.util.CharArrayWriter.write(CharArrayWriter.java:87)

at com.opensymphony.module.sitemesh.scalability.outputlength.OutputLengthObservantSitemeshWriter.write(OutputLengthObservantSitemeshWriter.java:51)

at java.base/java.io.PrintWriter.write(PrintWriter.java:541)

at java.base/java.io.PrintWriter.write(PrintWriter.java:558)

at com.opensymphony.module.sitemesh.filter.RoutablePrintWriter.write(RoutablePrintWriter.java:141)

at java.base/java.io.PrintWriter.append(PrintWriter.java:1087)

at java.base/java.io.PrintWriter.append(PrintWriter.java:61)

at com.google.template.soy.sharedpasses.render.RenderVisitor.append(RenderVisitor.java:762)

at com.google.template.soy.sharedpasses.render.RenderVisitor.visitRawTextNode(RenderVisitor.java:229)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:69)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:56)

at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:59)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitChildren(AbstractSoyNodeVisitor.java:129)

at com.google.template.soy.sharedpasses.render.RenderVisitor.visitBlockHelper(RenderVisitor.java:698)

at com.google.template.soy.sharedpasses.render.RenderVisitor.visitTemplateNode(RenderVisitor.java:220)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitTemplateBasicNode(AbstractSoyNodeVisitor.java:160)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:66)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:56)

at com.google.template.soy.basetree.AbstractNodeVisitor.exec(AbstractNodeVisitor.java:40)

at com.google.template.soy.sharedpasses.render.RenderVisitor.visitCallNodeHelper(RenderVisitor.java:590)

at com.google.template.soy.sharedpasses.render.RenderVisitor.visitCallBasicNode(RenderVisitor.java:457)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:110)

at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:56)

at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:59)

in gclog， G1 Evacuation Pause info shows memory usage go higher and finally there is no free memory to release ：

Pause Young (Normal) (G1 Evacuation Pause) 3681M->1732M(5120M) 32.304ms

Pause Young (Normal) (G1 Evacuation Pause) 3692M->1732M(5120M) 35.095ms

.....

Pause Young (Normal) (G1 Evacuation Pause) 5094M->5094M(5120M) 7.516ms

Pause Young (Normal) (G1 Evacuation Pause) 5099M->5099M(5120M) 9.413ms

Pause Young (Normal) (G1 Evacuation Pause) 5096M->5096M(5120M) 7.930ms

Stefan Stadler · Answer

Another question would also be, if you are running ScriptRunner and maybe do not close some resources over time.

But it is correct to collect a heap dump and analyze it. Everything else will just be guessing.

Tuncay Senturk _Snapbytes_ · Answer

Hi  @lynne

I don’t believe Jira 10.3.4 itself has a known memory leak.

The stack trace ending inside Soy writers is usually just the last straw before the JVM runs out of heap, not necessarily the root cause. One common culprit Atlassian highlights is very large comments or descriptions, which can trigger OOM/CPU spikes during rendering: Atlassian KB – OutOfMemory due to large comments or descriptions

The GC log you shared (5099M -> 5099M (5120M)) shows filling the heap. That’s consistent with requests holding large String objects during rendering, or potentially a plugin's service leak.

I’d recommend:

Enable heap dumps and detailed GC logs.

Reproduce the issue and then analyze the heap dump with Eclipse MAT to see which objects are retaining the most memory: KB – Analyze OutOfMemory errors with heap dumps