java.lang.OutOfMemoryError: PermGen space, Could't start SessionMaster ping

[Alex Black]

I've encountered this error 3 times, running Jetty and Maven, just
trying out Lift scala with a hello-world like website.

I have to kill the JVM with "kill -9" and restart things to fix it,
any ideas?
- Command line: "mvn install jetty:run"
- I'm using Lift 1.0, Scala 2.7.6 final, 64bit JDK1.6.0_16, on Ubuntu
Desktop x64.
- My app is trivial, no comet or actors or mapping, one view, one
class, lists records out of a postgres database table (which has 2
records in it, 2 columns)

Here are the errors from the terminal running jetty, I am not sure if
the actor/SessionMaster errors are related to the memory errors.

ERROR - Couldn't start SessionMaster ping
net.liftweb.util.ActorPingException: net.liftweb.http.SessionMaster
$CheckAndPurge$@7130bd0a could not be scheduled on
net.liftweb.http.SessionMaster$@36cb1594
at net.liftweb.util.ActorPing$.schedule(ActorPing.scala:51)
at net.liftweb.http.SessionMaster$.net$liftweb$http$SessionMaster$
$doPing(LiftSession.scala:209)
at net.liftweb.http.SessionMaster$$anonfun$act$1$$anonfun$apply
$1.apply(LiftSession.scala:200)
at net.liftweb.http.SessionMaster$$anonfun$act$1$$anonfun$apply
$1.apply(LiftSession.scala:169)
at scala.actors.Reaction.run(Reaction.scala:78)
at scala.actors.FJTask$Wrap.run(Unknown Source)
at scala.actors.FJTaskRunner.scanWhileIdling(Unknown Source)
at scala.actors.FJTaskRunner.run(Unknown Source)
Caused by: java.util.concurrent.RejectedExecutionException
at java.util.concurrent.ThreadPoolExecutor
$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1760)
at java.util.concurrent.ThreadPoolExecutor.reject
(ThreadPoolExecutor.java:767)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute
(ScheduledThreadPoolExecutor.java:216)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule
(ScheduledThreadPoolExecutor.java:379)
at java.util.concurrent.Executors
$DelegatedScheduledExecutorService.schedule(Executors.java:654)
at net.liftweb.util.ActorPing$.schedule(ActorPing.scala:49)
... 7 more
INFO - Service request (GET) / took 1411 Milliseconds
INFO - Service request (GET) /classpath/jquery.js took 7 Milliseconds
[INFO] restarting
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@5dbb6a69{/,/home/
alex/dev/poc/src/main/webapp}
2009-10-08 14:06:44.221::WARN: Error for /ajax_request/liftAjax.js
java.lang.OutOfMemoryError: PermGen space
2009-10-08 14:06:47.424::WARN: failed LiftFilter:
java.lang.OutOfMemoryError: PermGen space
2009-10-08 14:06:48.053::WARN: failed ServletHandler@4838ddcc:
java.lang.OutOfMemoryError: PermGen space
2009-10-08 14:06:48.053::WARN: failed SecurityHandler@d69a11f:
java.lang.OutOfMemoryError: PermGen space
2009-10-08 14:06:48.053::WARN: failed SessionHandler@11d1011a:
java.lang.OutOfMemoryError: PermGen space
2009-10-08 14:06:48.053::WARN: failed
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@5dbb6a69{/,/home/
alex/dev/poc/src/main/webapp}: java.lang.OutOfMemoryError: PermGen
space
2009-10-08 14:06:48.053::WARN: EXCEPTION
java.lang.OutOfMemoryError: PermGen space
Exception in thread "Timer-1" java.lang.OutOfMemoryError: PermGen
space

[Timothy Perrett]

Alex,

Any reason your running the install goal? You really don't need to.

Regarding the permgen: Can you show your maven options? You can
improve the situation by setting a larger heap size, however this is
an unfortunate thing that just goes along with jetty and maven.

HTH

Cheers, Tim

[jon]

Hi,

Is this error occurring after a context reload? You may want to turn
off context reloading in your mvn jetty configuration because, as far
as i can tell, that has always been a completely broken feature.
Do this by adding <scanIntervalSeconds>0</scanIntervalSeconds> to the
"org.mortbay.jetty" <configuration/>

You can setup javarebel if you want to avoid restarting the container
for minor code changes. You may still run into permgen issues as
javarebel reloads classes too. But, these JVM flags will help reduce
the frequency further:
-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m

(add to your MAVEN_OPTS env variable)

I would also suggest looking into sbt as the continuous compilation is
much more robust than scala:cc (it keeps track of dependencies and
will recompile the entire tree). The only downside is there's no yui
compressor plugin, yet.

- Jon

[Alex Black]

Hi Tim, I'm not sure even what "install goal" means. I'm new to Maven,
Jetty and Scala, so I'm following examples I've read. Whats the
better approach here?

export MAVEN_OPTS="-Xms256m -Xmx1024m"

On Oct 8, 2:16 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:

[Alex Black]

Hi Jon,

I haven't narrowed it down to being after a context reload or not.

I'll try what you suggested and turn off jetty's reload and use
javaRebel instead.

Where would I set those JVM flags, should those go in MAVEN_OPTS?

I'll keep SBT in mind...

- ALex

[jon]

Yes,

I think this will get you going with javarebel:

MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m -
Xmx512m -noverify -javaagent:/path/to/jrebel-2.1/jrebel.jar" mvn
jetty:run

in another terminal window
mvn scala:cc

get a free license here: http://www.zeroturnaround.com/scala-license/

- Jon

[Timothy Perrett]

Javarebel will certainly help here, but it wont solve the problem
entirely as there are always going to be somethings that it cannot
replace dynamically.

Regarding the question about goals, this is the maven syntax:

mvn <goal> <goal>... etc

so, install, and jetty:run are goals in maven terminology.

Cheers, Tim

[Rob Saul]

A colleague of mine found these interesting articles regarding PerGen issues :

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

~Rob