jira 10.3.4 keep oom when running a period time

[lynne]

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

[Tuncay Senturk _Snapbytes_]

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