Play upgrade 2.4.6 to 2.6.21 | OutOfMemoryError: Java heap space

Play Framework
1

Hi, I think I’m almost done with Play upgrade 2.4.6 to 2.6.21. Problem I’m facing right now is the Heap out of memory, When I sbt run the service on localhost first time after sbt clean compile it gives:

[error] a.a.ActorSystemImpl - Internal server error, sending 500 response
java.security.PrivilegedActionException: null
	at java.security.AccessController.doPrivileged(Native Method)
	at play.runsupport.Reloader$.play$runsupport$Reloader$$withReloaderContextClassLoader(Reloader.scala:55)
	at play.runsupport.Reloader.reload(Reloader.scala:412)
	at play.core.server.DevServerStart$$anon$1.get(DevServerStart.scala:123)
	at play.core.server.AkkaHttpServer.handleRequest(AkkaHttpServer.scala:241)
	at play.core.server.AkkaHttpServer.$anonfun$createServerBinding$1(AkkaHttpServer.scala:138)
	at akka.stream.impl.fusing.MapAsyncUnordered$$anon$31.onPush(Ops.scala:1318)
	at akka.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:519)
	at akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:482)
	at akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:378)
Caused by: java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at sbt.ConcurrentRestrictions$$anon$4.take(ConcurrentRestrictions.scala:213)
	at sbt.Execute.next$1(Execute.scala:110)
	at sbt.Execute.processAll(Execute.scala:113)
	at sbt.Execute.runKeep(Execute.scala:90)
	at sbt.EvaluateTask$.liftedTree1$1(EvaluateTask.scala:420)
	at sbt.EvaluateTask$.run$1(EvaluateTask.scala:419)
	at sbt.EvaluateTask$.runTask(EvaluateTask.scala:438)
	at sbt.EvaluateTask$.$anonfun$apply$3(EvaluateTask.scala:313)
Caused by: java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
	at java.lang.StringBuilder.append(StringBuilder.java:136)
	at sjsonnew.support.scalajson.unsafe.JsonPrinter.printString(JsonPrinter.scala:65)
	at sjsonnew.support.scalajson.unsafe.JsonPrinter.printString$(JsonPrinter.scala:58)
	at sjsonnew.support.scalajson.unsafe.CompactPrinter$.printString(CompactPrinter.scala:54)
	at sjsonnew.support.scalajson.unsafe.JsonPrinter.printLeaf(JsonPrinter.scala:53)
	at sjsonnew.support.scalajson.unsafe.JsonPrinter.printLeaf$(JsonPrinter.scala:47)
	at sjsonnew.support.scalajson.unsafe.CompactPrinter$.printLeaf(CompactPrinter.scala:54)

But only first time, then it behaves nice after ctrl+c and again sbt run. I’m not sure what’s wrong and what do I need to change to ignore this. The HPROF didn’t show any memory leaks though.

2

Can you share the min/max heap settings? Also are you trying to walk/print a very big json as the stacktrace suggests?

3

@aditya I haven’t set any min/max explicitly, it must be taking the defaults:

$ sbt -v console
[process_args] java_version = '8'
# Executing command line:
java
-Xms1024m
-Xmx1024m
-XX:ReservedCodeCacheSize=128m
-XX:MaxMetaspaceSize=256m
-jar
/usr/share/sbt/bin/sbt-launch.jar
console

I’m not about walk, but yeah there are some instances of logging a JSON response as info, no printlns are there.

4

Those heap settings should be sufficient. Also since you mention you are seeing the error as soon as you hit the server, you could try couple of options:

1.) Enable verbosegc output for the JVM to give you the major/minor GC collections.
2.) Open a jvisualvm console and observe the pattern of memory growth.

If that doesnt help much,

1.) Try commenting those problematic JSON responses if you suspect they could be contributing to the OOM.
2.) Profile the code for memory with standard profiler (Yourkit, JProfiler etc.) to know the top memory consuming objects.

HTH

5

Thanks @aditya, I’ll try and post the results.