[2.0.1-java] Error during sbt execution: OutOfMemoryError

[J. O. Meyer]

Hi,

I have several times encountered the same error now after working with Play for several hours and frequent starting and stopping the application:

Here is the error message:

[info] play - Application started (Dev)

Exception in thread "pool-592-thread-1" java.lang.OutOfMemoryError: PermGen space

sbt appears to be exiting abnormally.

  The log file for this session is at C:\Users\...\AppData\Local\Temp\sbt8431069139275026395.log

java.lang.OutOfMemoryError: PermGen space

Error during sbt execution: java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-6" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-42" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-54" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-70" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-66" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-14" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-2" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-30" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-22" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-58" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-34" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-62" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-50" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-18" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-46" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-10" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-26" java.lang.OutOfMemoryError: PermGen space

Exception in thread "Thread-38" java.lang.OutOfMemoryError: PermGen space

And here is the log file:

[debug] Running task... Cancelable: true, max worker threads: 2, check cycles: false

[info] Compiling 1 Scala source to C:\Users\...\modules\common\target\scala-2.9.1\classes...

[debug] Running task... Cancelable: true, max worker threads: 2, check cycles: false

[debug] Running task... Cancelable: true, max worker threads: 2, check cycles: false

[debug] Running task... Cancelable: true, max worker threads: 2, check cycles: false

[debug] Running task... Cancelable: true, max worker threads: 2, check cycles: false

I'm using Play 2.0.1 on a Windows machine with JDK 1.6.0_30.

Does anybody encounter the same behaviour ?

Any idea where this comes from ?

Thanks,

J.

[Aishwarya Singhal]

try increasing the perm gen space (-XX:MaxPermSize) ?

[Kevin Bosman]

> > I have several times encountered the same error now after working with Play
> > for several hours and frequent starting and stopping the application:

> > java.lang.OutOfMemoryError: PermGen space

Happens quite frequently for us on both Windows and even on Linux with
a 2GB heap and 512MB permsize.
Same as you say, after several hours of recompiling and frequent
start/stops. Memory usage slows creeps up until it reports
OutOfMemory.
Pure speculation, but it could be somehow related to ebean caching.

[Joerg Meyer]

hm, I wonder why there are so many open threads. My application is
actually quite simple so far.

I'm a bit worried that this behaviour might occur in productive
deployment as well.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
>
>

[peter hausel]

this issue is not related to play per se (third party libs sometimes are leaking permgen). 

If you see this issue, for now you can do:  `sh play test` from the console (this will run the tests in a forked jvm)

the ultimate solution is going to be upgrading to sbt 0.13 (once it's out). This version of sbt will let us run tests in a forked JVM.

Hope this helps.

Cheers,

Peter

On Thursday, May 31, 2012 9:44:19 AM UTC-4, J. O. Meyer wrote:

hm, I wonder why there are so many open threads. My application is
actually quite simple so far.

I'm a bit worried that this behaviour might occur in productive
deployment as well.


On 5/29/12, Kevin Bosman <ke...@gosh.co.za> wrote:
>> > I have several times encountered the same error now after working with
>> > Play
>> > for several hours and frequent starting and stopping the application:
>
>> > java.lang.OutOfMemoryError: PermGen space
>
> Happens quite frequently for us on both Windows and even on Linux with
> a 2GB heap and 512MB permsize.
> Same as you say, after several hours of recompiling and frequent
> start/stops. Memory usage slows creeps up until it reports
> OutOfMemory.
> Pure speculation, but it could be somehow related to ebean caching.
>
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To post to this group, send email to play-framework@googlegroups.com.

> To unsubscribe from this group, send email to

> play-framework+unsubscribe@googlegroups.com.

[Kevin Bosman]

> I'm a bit worried that this behaviour might occur in productive
> deployment as well.

I can confirm it does not happen in production, so don't worry about that.

In dev mode, just remember to restart the play console every couple of
hours and you'll never encounter the problem.
If it starts reporting out of memory, just kill the sbt jvm and start
play again.

[J. O. Meyer]

Thanks, Peter & Kevin. That's good to know :-)

Makes me sleep better at night now ;-)

[Mike Bryant]

I started encountering this PermGen space crash persistently when running my specs tests with Play 2.1-SNAPSHOT. None of the various fixes (mainly setting MaxPermSize in various places) seem to work.

However, I did recall that I'd recently switched my java and javac to sun1.6 from oracle1.7. Switching back to oracle1.7 has fixed the issue for now.

I thought I'd post that lone data point in case it helps anyone else.