ok still not a solution. and my jetty process will hang every 5 minutes.
in the mean time i do this:
perl kill-jetty.pl & mvn jetty:run &
in my kill-jetty.pl i have:
---------------------------------------
$_=`ps aux | grep jetty | grep -v grep | grep -v perl`;
if(~/(\d+)/){
`kill -9 $1`;
}
#remove the # if you want to run mvn from perl (output will not be on
the console)
#`mvn jetty:run &`
----------------------------------------
or has someone the right java_opts??
mine are:
export JAVA_OPTS="-Xms256M -Xmx256M -XX:MaxPermSize=556M
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled"
ciao,
tibi
Rob van Oostrum wrote:
This is the reference I've been using a lot lately:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
-XX:+UseConcMarkSweepGC works well on hosts with fewer than 2 CPUs. If
you're lucky enough to have a 4-way (or - *gasp* - more) box to play
with, -XX:+UseParallelGC is probably the better option. Depending on
your application / application server profile it may be faster to use
-XX:+UseParallelGC on a 2-way (or dual core) box, but it's probably a
toss-up.
I use jvmstat (http://java.sun.com/performance/jvmstat/) to examine
the makeup of a heap and tune the sizes of the various components
accordingly. It's got virtually no performance overhead. I've been
using it to troubleshoot production environments.
Cheers
Rob
On 3/14/07, Matt Raible <[EMAIL PROTECTED]> wrote:
Here's something else to try if you're getting OOM errors when running
"mvn jetty:run". Most of these settings can go in a JAVA_OPTS or
MAVEN_OPTS environment variable.
http://my.opera.com/karmazilla/blog/2007/03/13/good-riddance-permgen-outofmemoryerror
Matt
On 3/11/07, Philip Barlow <[EMAIL PROTECTED]> wrote:
> Interesting, are you deploying using Jetty and have you at any stage
> changed memory arguments for your JVM, Maven or anything else that
might
> be associated with the build/test/deploy process?
>
> Also what do the following 2 commands return when typed at the
command line:
>
> echo %JAVA_HOME%
> java -version
>
> Thanks
>
> Philip
>
> wnqq wrote:
> > Regarding surefire, I use default settings (i.e., Sun JVM) for
tests and it
> > works every time too.
> >
> >
> > Philip Barlow wrote:
> >
> >> I had this problem in work recently, i set surefire to use
JRockit as
> >> the JVM for tests and it worked every time. I realise this is
not a fix
> >> but i have read alot about this subject and there a very differing
> >> opinions on it. Matt is correct in stating that resources are
not being
> >> released but JRockit seems to do ok in this respect.
> >>
> >> This would be helpfull if you decide to take this course of action.
> >>
> >>
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
> >>
> >>
> >>
> >> Matt Raible wrote:
> >>
> >>> I have MaxPermSize set to 256M on my system and I still get
this issue
> >>> every 5-10 minutes. My guess is resources aren't being let go.
I've
> >>> heard bad things about Spring and Hibernate in the past, so I
don't
> >>> know if they're causing this or what. The best thing is
probably to
> >>> slap a profiler on it and see where the hotspots and memory
leaks are.
> >>>
> >>> Matt
> >>>
> >>> On 3/7/07, wnqq <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Environment: v2.0-m4-SNAPSHOT
> >>>>
> >>>> It is too often to get "java.lang.OutOfMemoryError: PermGen
space" while
> >>>> executing "mvn jetty:run".
> >>>>
> >>>> How to resolve it?
> >>>>
> >>>> I know that traditionally we could specify the JVM parameters
like
> >>>> "-Xmx512M
> >>>> -XX:PermSize=64M -XX:MaxPermSize=128M" to increase the memory
size.
> >>>> How does
> >>>> this apply to appfuse/mvn?
> >>>> --
> >>>> View this message in context:
> >>>>
http://www.nabble.com/mvn-jetty%3Arun-%3D%3E-OutOfMemoryError%3A-PermGen-space-tf3367253s2369.html#a9368515
> >>>>
> >>>>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
http://raibledesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
