AppFuse › AppFuse - User

mvn jetty:run => OutOfMemoryError: PermGen space

Classic

List

Threaded

24 messages Options

wnqq

mvn jetty:run => OutOfMemoryError: PermGen space

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?

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

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 <[hidden email]> 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
> Sent from the AppFuse - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

wolrabp

Re: mvn jetty:run => OutOfMemoryError: PermGen space

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 <[hidden email]> 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
>>
>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

Philip,

What's your configuration for this look like? I'm assuming you just
use JRockit for your tests, but you still use Sun's JVM for "mvn
jetty:run"?

Matt

On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
> >>
> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

wolrabp

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Yes, exactly, surefire allows you to specify an independent JVM for
tests, separate to your deployment JVM. We use Suns JVM for deployment
and JRockit for tests now. the JVM can be declared in your POM under the
configuration for the surefire-plugin. If you need any more info on this
let me know.

Matt Raible wrote:

> Philip,
>
> What's your configuration for this look like? I'm assuming you just
> use JRockit for your tests, but you still use Sun's JVM for "mvn
> jetty:run"?
>
> Matt
>
> On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
>>
>> >>
>> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

An XML snippet would be great. Do you think it's possible to delegate
to one Sun JVM for testing and another for running? For example, test
under JDK 5, run under JDK 6.

Matt

On 3/8/07, Philip Barlow <[hidden email]> wrote:

> Yes, exactly, surefire allows you to specify an independent JVM for
> tests, separate to your deployment JVM. We use Suns JVM for deployment
> and JRockit for tests now. the JVM can be declared in your POM under the
> configuration for the surefire-plugin. If you need any more info on this
> let me know.
>
> Matt Raible wrote:
> > Philip,
> >
> > What's your configuration for this look like? I'm assuming you just
> > use JRockit for your tests, but you still use Sun's JVM for "mvn
> > jetty:run"?
> >
> > Matt
> >
> > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
> >>
> >> >>
> >> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

JRockit in general seems to work great. I installed it about an hour
ago and did some testing. I was able to run "mvn jetty:run" and
compile classes (to invoke a restart) about 15 times. I gave up after
that. With Sun's JDK 6, I get a PermGen error after reload #4.

Summary: Use JRockit for developing AppFuse!

http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp

If you're developing an AppFuse 2.x-based application, please download
JRockit and try it out. I'll check back next week and see how it's
going for everyone. If good, we'll change the download link to
JRockit on the QuickStart Guide.

Matt

P.S. I don't think this means you have to use JRockit for production,
just when you're reloading a lot during development.

On 3/8/07, Matt Raible <[hidden email]> wrote:

> An XML snippet would be great. Do you think it's possible to delegate
> to one Sun JVM for testing and another for running? For example, test
> under JDK 5, run under JDK 6.
>
> Matt
>
> On 3/8/07, Philip Barlow <[hidden email]> wrote:
> > Yes, exactly, surefire allows you to specify an independent JVM for
> > tests, separate to your deployment JVM. We use Suns JVM for deployment
> > and JRockit for tests now. the JVM can be declared in your POM under the
> > configuration for the surefire-plugin. If you need any more info on this
> > let me know.
> >
> > Matt Raible wrote:
> > > Philip,
> > >
> > > What's your configuration for this look like? I'm assuming you just
> > > use JRockit for your tests, but you still use Sun's JVM for "mvn
> > > jetty:run"?
> > >
> > > Matt
> > >
> > > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
> > >>
> > >> >>
> > >> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: [hidden email]
> > >> >> For additional commands, e-mail: [hidden email]
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> http://raibledesigns.com
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

Maybe I spoke too soon, it looks like there's issues using JRockit
with the native2ascii plugin:

[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error starting Sun's native2ascii:
sun.tools.native2ascii.Main
[INFO] ------------------------------------------------------------------------
[INFO] Trace
Error starting Sun's native2ascii:
at org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
ava:67)
at org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
tive2Ascii.java:54)
at org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
at org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
at org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
at org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
ycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
ava:51)
... 23 more
--- Nested Exception ---
java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
ava:51)
at org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
tive2Ascii.java:54)
at org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
at org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
at org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
at org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
ycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 minutes 2 seconds
[INFO] Finished at: Thu Mar 08 11:34:49 MST 2007
[INFO] Final Memory: 226M/512M
[INFO] ------------------------------------------------------------------------
$

On 3/8/07, Matt Raible <[hidden email]> wrote:

> JRockit in general seems to work great. I installed it about an hour
> ago and did some testing. I was able to run "mvn jetty:run" and
> compile classes (to invoke a restart) about 15 times. I gave up after
> that. With Sun's JDK 6, I get a PermGen error after reload #4.
>
> Summary: Use JRockit for developing AppFuse!
>
> http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
>
> If you're developing an AppFuse 2.x-based application, please download
> JRockit and try it out. I'll check back next week and see how it's
> going for everyone. If good, we'll change the download link to
> JRockit on the QuickStart Guide.
>
> Matt
>
> P.S. I don't think this means you have to use JRockit for production,
> just when you're reloading a lot during development.
>
> On 3/8/07, Matt Raible <[hidden email]> wrote:
> > An XML snippet would be great. Do you think it's possible to delegate
> > to one Sun JVM for testing and another for running? For example, test
> > under JDK 5, run under JDK 6.
> >
> > Matt
> >
> > On 3/8/07, Philip Barlow <[hidden email]> wrote:
> > > Yes, exactly, surefire allows you to specify an independent JVM for
> > > tests, separate to your deployment JVM. We use Suns JVM for deployment
> > > and JRockit for tests now. the JVM can be declared in your POM under the
> > > configuration for the surefire-plugin. If you need any more info on this
> > > let me know.
> > >
> > > Matt Raible wrote:
> > > > Philip,
> > > >
> > > > What's your configuration for this look like? I'm assuming you just
> > > > use JRockit for your tests, but you still use Sun's JVM for "mvn
> > > > jetty:run"?
> > > >
> > > > Matt
> > > >
> > > > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
> > > >>
> > > >> >>
> > > >> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
> > > >> >>
> > > >> >> ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: [hidden email]
> > > >> >> For additional commands, e-mail: [hidden email]
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > http://raibledesigns.com
> >
>
>
> --
> http://raibledesigns.com
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

Copying $JROCKIT_HOME/lib/tools.jar to
$JROCKIT_HOME/jre/lib/ext/tools.jar fixed this problem. The reason
this happened is probably because I chose *not* to use JRockit as my
default JRE.

Matt

On 3/8/07, Matt Raible <[hidden email]> wrote:

> Maybe I spoke too soon, it looks like there's issues using JRockit
> with the native2ascii plugin:
>
> [ERROR] FATAL ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Error starting Sun's native2ascii:
> sun.tools.native2ascii.Main
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> Error starting Sun's native2ascii:
> at org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
> ava:67)
> at org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
> tive2Ascii.java:54)
> at org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
> at org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
> at org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
> at org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
> .java:539)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
> ycleExecutor.java:480)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
> java:459)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
> ifecycleExecutor.java:311)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
> xecutor.java:278)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
> :143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:164)
> at org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
> ava:51)
> ... 23 more
> --- Nested Exception ---
> java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:164)
> at org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
> ava:51)
> at org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
> tive2Ascii.java:54)
> at org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
> at org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
> at org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
> at org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
> .java:539)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
> ycleExecutor.java:480)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
> java:459)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
> ifecycleExecutor.java:311)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
> xecutor.java:278)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
> :143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 4 minutes 2 seconds
> [INFO] Finished at: Thu Mar 08 11:34:49 MST 2007
> [INFO] Final Memory: 226M/512M
> [INFO] ------------------------------------------------------------------------
> $
>
> On 3/8/07, Matt Raible <[hidden email]> wrote:
> > JRockit in general seems to work great. I installed it about an hour
> > ago and did some testing. I was able to run "mvn jetty:run" and
> > compile classes (to invoke a restart) about 15 times. I gave up after
> > that. With Sun's JDK 6, I get a PermGen error after reload #4.
> >
> > Summary: Use JRockit for developing AppFuse!
> >
> > http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
> >
> > If you're developing an AppFuse 2.x-based application, please download
> > JRockit and try it out. I'll check back next week and see how it's
> > going for everyone. If good, we'll change the download link to
> > JRockit on the QuickStart Guide.
> >
> > Matt
> >
> > P.S. I don't think this means you have to use JRockit for production,
> > just when you're reloading a lot during development.
> >
> > On 3/8/07, Matt Raible <[hidden email]> wrote:
> > > An XML snippet would be great. Do you think it's possible to delegate
> > > to one Sun JVM for testing and another for running? For example, test
> > > under JDK 5, run under JDK 6.
> > >
> > > Matt
> > >
> > > On 3/8/07, Philip Barlow <[hidden email]> wrote:
> > > > Yes, exactly, surefire allows you to specify an independent JVM for
> > > > tests, separate to your deployment JVM. We use Suns JVM for deployment
> > > > and JRockit for tests now. the JVM can be declared in your POM under the
> > > > configuration for the surefire-plugin. If you need any more info on this
> > > > let me know.
> > > >
> > > > Matt Raible wrote:
> > > > > Philip,
> > > > >
> > > > > What's your configuration for this look like? I'm assuming you just
> > > > > use JRockit for your tests, but you still use Sun's JVM for "mvn
> > > > > jetty:run"?
> > > > >
> > > > > Matt
> > > > >
> > > > > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
> > > > >>
> > > > >> >>
> > > > >> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
> > > > >> >>
> > > > >> >> ---------------------------------------------------------------------
> > > > >> >> To unsubscribe, e-mail: [hidden email]
> > > > >> >> For additional commands, e-mail: [hidden email]
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: [hidden email]
> > > > >> For additional commands, e-mail: [hidden email]
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > >
> > > --
> > > http://raibledesigns.com
> > >
> >
> >
> > --
> > http://raibledesigns.com
> >
>
>
> --
> http://raibledesigns.com
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

wolrabp

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Ok, what i done was added the following under plugins in the POM:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<jvm>${JROCKIT_HOME}/java/bin</jvm>
</configuration>
</plugin>

JROCKIT_HOME is a windows environment variable i setup to point to the
directory containing JRockit. Just to reiterate for everyone, this means
you are only using JRockit for testing.

One thing i did notice when trying to get to the bottom of this problem
was when running the tests with Suns JVM 1.5, the java.exe process,
viewed using task manager, consistently hit about 96mb before giving an
out of memory PermGen space error. I take it this 96mb is a setting
specified somewhere but i don't know where?

Matt Raible wrote:

> Copying $JROCKIT_HOME/lib/tools.jar to
> $JROCKIT_HOME/jre/lib/ext/tools.jar fixed this problem. The reason
> this happened is probably because I chose *not* to use JRockit as my
> default JRE.
>
> Matt
>
> On 3/8/07, Matt Raible <[hidden email]> wrote:
>> Maybe I spoke too soon, it looks like there's issues using JRockit
>> with the native2ascii plugin:
>>
>> [ERROR] FATAL ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Error starting Sun's native2ascii:
>> sun.tools.native2ascii.Main
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Trace
>> Error starting Sun's native2ascii:
>> at
>> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
>>
>> ava:67)
>> at
>> org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
>>
>> tive2Ascii.java:54)
>> at
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
>>
>> at
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
>>
>> at
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
>>
>> at
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
>>
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
>>
>> .java:539)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
>>
>> ycleExecutor.java:480)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
>>
>> java:459)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
>>
>> ifecycleExecutor.java:311)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
>>
>> xecutor.java:278)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
>>
>> :143)
>> at
>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> at
>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> Caused by: java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:164)
>> at
>> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
>>
>> ava:51)
>> ... 23 more
>> --- Nested Exception ---
>> java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:164)
>> at
>> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
>>
>> ava:51)
>> at
>> org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
>>
>> tive2Ascii.java:54)
>> at
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
>>
>> at
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
>>
>> at
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
>>
>> at
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
>>
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
>>
>> .java:539)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
>>
>> ycleExecutor.java:480)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
>>
>> java:459)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
>>
>> ifecycleExecutor.java:311)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
>>
>> xecutor.java:278)
>> at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
>>
>> :143)
>> at
>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> at
>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 4 minutes 2 seconds
>> [INFO] Finished at: Thu Mar 08 11:34:49 MST 2007
>> [INFO] Final Memory: 226M/512M
>> [INFO]
>> ------------------------------------------------------------------------
>> $
>>
>> On 3/8/07, Matt Raible <[hidden email]> wrote:
>> > JRockit in general seems to work great. I installed it about an hour
>> > ago and did some testing. I was able to run "mvn jetty:run" and
>> > compile classes (to invoke a restart) about 15 times. I gave up after
>> > that. With Sun's JDK 6, I get a PermGen error after reload #4.
>> >
>> > Summary: Use JRockit for developing AppFuse!
>> >
>> > http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
>> >
>> > If you're developing an AppFuse 2.x-based application, please download
>> > JRockit and try it out. I'll check back next week and see how it's
>> > going for everyone. If good, we'll change the download link to
>> > JRockit on the QuickStart Guide.
>> >
>> > Matt
>> >
>> > P.S. I don't think this means you have to use JRockit for production,
>> > just when you're reloading a lot during development.
>> >
>> > On 3/8/07, Matt Raible <[hidden email]> wrote:
>> > > An XML snippet would be great. Do you think it's possible to
>> delegate
>> > > to one Sun JVM for testing and another for running? For example,
>> test
>> > > under JDK 5, run under JDK 6.
>> > >
>> > > Matt
>> > >
>> > > On 3/8/07, Philip Barlow <[hidden email]> wrote:
>> > > > Yes, exactly, surefire allows you to specify an independent JVM
>> for
>> > > > tests, separate to your deployment JVM. We use Suns JVM for
>> deployment
>> > > > and JRockit for tests now. the JVM can be declared in your POM
>> under the
>> > > > configuration for the surefire-plugin. If you need any more
>> info on this
>> > > > let me know.
>> > > >
>> > > > Matt Raible wrote:
>> > > > > Philip,
>> > > > >
>> > > > > What's your configuration for this look like? I'm assuming
>> you just
>> > > > > use JRockit for your tests, but you still use Sun's JVM for "mvn
>> > > > > jetty:run"?
>> > > > >
>> > > > > Matt
>> > > > >
>> > > > > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
>>
>> > > > >>
>> > > > >> >>
>> > > > >> >> Sent from the AppFuse - User mailing list archive at
>> Nabble.com.
>> > > > >> >>
>> > > > >> >>
>> ---------------------------------------------------------------------
>> > > > >> >> To unsubscribe, e-mail:
>> [hidden email]
>> > > > >> >> For additional commands, e-mail:
>> [hidden email]
>> > > > >> >>
>> > > > >> >>
>> > > > >> >
>> > > > >> >
>> > > > >>
>> > > > >>
>> ---------------------------------------------------------------------
>> > > > >> To unsubscribe, e-mail: [hidden email]
>> > > > >> For additional commands, e-mail:
>> [hidden email]
>> > > > >>
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: [hidden email]
>> > > > For additional commands, e-mail: [hidden email]
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > http://raibledesigns.com
>> > >
>> >
>> >
>> > --
>> > http://raibledesigns.com
>> >
>>
>>
>> --
>> http://raibledesigns.com
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

wolrabp

Re: mvn jetty:run => OutOfMemoryError: PermGen space

In reply to this post by mraible

Haven't tried this but it may solve the problem while still using the
default JVM

http://maven.apache.org/plugins/maven-surefire-plugin/examples/forking.html

Matt Raible wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

I don't know how these settings will affect "mvn jetty:run" - the
surefire plugin isn't executed during a reload of the app in Jetty.

Matt

On 3/8/07, Philip Barlow <[hidden email]> wrote:

> Haven't tried this but it may solve the problem while still using the
> default JVM
>
> http://maven.apache.org/plugins/maven-surefire-plugin/examples/forking.html
>
>
> Matt Raible wrote:
> > Copying $JROCKIT_HOME/lib/tools.jar to
> > $JROCKIT_HOME/jre/lib/ext/tools.jar fixed this problem. The reason
> > this happened is probably because I chose *not* to use JRockit as my
> > default JRE.
> >
> > Matt
> >
> > On 3/8/07, Matt Raible <[hidden email]> wrote:
> >> Maybe I spoke too soon, it looks like there's issues using JRockit
> >> with the native2ascii plugin:
> >>
> >> [ERROR] FATAL ERROR
> >> [INFO]
> >> ------------------------------------------------------------------------
> >> [INFO] Error starting Sun's native2ascii:
> >> sun.tools.native2ascii.Main
> >> [INFO]
> >> ------------------------------------------------------------------------
> >> [INFO] Trace
> >> Error starting Sun's native2ascii:
> >> at
> >> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
> >>
> >> ava:67)
> >> at
> >> org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
> >>
> >> tive2Ascii.java:54)
> >> at
> >> org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
> >>
> >> at
> >> org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
> >>
> >> at
> >> org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
> >>
> >> at
> >> org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
> >>
> >> at
> >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> >>
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
> >>
> >> .java:539)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
> >>
> >> ycleExecutor.java:480)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
> >>
> >> java:459)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
> >>
> >> ifecycleExecutor.java:311)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
> >>
> >> xecutor.java:278)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
> >>
> >> :143)
> >> at
> >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >>
> >> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:585)
> >> at
> >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> >> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> >> at
> >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> >> Caused by: java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
> >> at java.lang.Class.forName0(Native Method)
> >> at java.lang.Class.forName(Class.java:164)
> >> at
> >> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
> >>
> >> ava:51)
> >> ... 23 more
> >> --- Nested Exception ---
> >> java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
> >> at java.lang.Class.forName0(Native Method)
> >> at java.lang.Class.forName(Class.java:164)
> >> at
> >> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
> >>
> >> ava:51)
> >> at
> >> org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
> >>
> >> tive2Ascii.java:54)
> >> at
> >> org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
> >>
> >> at
> >> org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
> >>
> >> at
> >> org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
> >>
> >> at
> >> org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
> >>
> >> at
> >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> >>
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
> >>
> >> .java:539)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
> >>
> >> ycleExecutor.java:480)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
> >>
> >> java:459)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
> >>
> >> ifecycleExecutor.java:311)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
> >>
> >> xecutor.java:278)
> >> at
> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
> >>
> >> :143)
> >> at
> >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >>
> >> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:585)
> >> at
> >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> >> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> >> at
> >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> >> [INFO]
> >> ------------------------------------------------------------------------
> >> [INFO] Total time: 4 minutes 2 seconds
> >> [INFO] Finished at: Thu Mar 08 11:34:49 MST 2007
> >> [INFO] Final Memory: 226M/512M
> >> [INFO]
> >> ------------------------------------------------------------------------
> >> $
> >>
> >> On 3/8/07, Matt Raible <[hidden email]> wrote:
> >> > JRockit in general seems to work great. I installed it about an hour
> >> > ago and did some testing. I was able to run "mvn jetty:run" and
> >> > compile classes (to invoke a restart) about 15 times. I gave up after
> >> > that. With Sun's JDK 6, I get a PermGen error after reload #4.
> >> >
> >> > Summary: Use JRockit for developing AppFuse!
> >> >
> >> > http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
> >> >
> >> > If you're developing an AppFuse 2.x-based application, please download
> >> > JRockit and try it out. I'll check back next week and see how it's
> >> > going for everyone. If good, we'll change the download link to
> >> > JRockit on the QuickStart Guide.
> >> >
> >> > Matt
> >> >
> >> > P.S. I don't think this means you have to use JRockit for production,
> >> > just when you're reloading a lot during development.
> >> >
> >> > On 3/8/07, Matt Raible <[hidden email]> wrote:
> >> > > An XML snippet would be great. Do you think it's possible to
> >> delegate
> >> > > to one Sun JVM for testing and another for running? For example,
> >> test
> >> > > under JDK 5, run under JDK 6.
> >> > >
> >> > > Matt
> >> > >
> >> > > On 3/8/07, Philip Barlow <[hidden email]> wrote:
> >> > > > Yes, exactly, surefire allows you to specify an independent JVM
> >> for
> >> > > > tests, separate to your deployment JVM. We use Suns JVM for
> >> deployment
> >> > > > and JRockit for tests now. the JVM can be declared in your POM
> >> under the
> >> > > > configuration for the surefire-plugin. If you need any more
> >> info on this
> >> > > > let me know.
> >> > > >
> >> > > > Matt Raible wrote:
> >> > > > > Philip,
> >> > > > >
> >> > > > > What's your configuration for this look like? I'm assuming
> >> you just
> >> > > > > use JRockit for your tests, but you still use Sun's JVM for "mvn
> >> > > > > jetty:run"?
> >> > > > >
> >> > > > > Matt
> >> > > > >
> >> > > > > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
> >>
> >> > > > >>
> >> > > > >> >>
> >> > > > >> >> Sent from the AppFuse - User mailing list archive at
> >> Nabble.com.
> >> > > > >> >>
> >> > > > >> >>
> >> ---------------------------------------------------------------------
> >> > > > >> >> To unsubscribe, e-mail:
> >> [hidden email]
> >> > > > >> >> For additional commands, e-mail:
> >> [hidden email]
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >> >
> >> > > > >> >
> >> > > > >>
> >> > > > >>
> >> ---------------------------------------------------------------------
> >> > > > >> To unsubscribe, e-mail: [hidden email]
> >> > > > >> For additional commands, e-mail:
> >> [hidden email]
> >> > > > >>
> >> > > > >>
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: [hidden email]
> >> > > > For additional commands, e-mail: [hidden email]
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > http://raibledesigns.com
> >> > >
> >> >
> >> >
> >> > --
> >> > http://raibledesigns.com
> >> >
> >>
> >>
> >> --
> >> http://raibledesigns.com
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

wolrabp

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Right, i think we are talking about 2 different problems here. I am
specifically referring to testing as i have never gotten an out of
memory error when restarting using BEA Weblogic 8.1/9.1/9.2. Might be
interesting for a few people to experiment using Jetty with JRockit for
a while as you suggested. Put it to the test....

Matt Raible wrote:

> I don't know how these settings will affect "mvn jetty:run" - the
> surefire plugin isn't executed during a reload of the app in Jetty.
>
> Matt
>
> On 3/8/07, Philip Barlow <[hidden email]> wrote:
>> Haven't tried this but it may solve the problem while still using the
>> default JVM
>>
>> http://maven.apache.org/plugins/maven-surefire-plugin/examples/forking.html
>>
>>
>>
>> Matt Raible wrote:
>> > Copying $JROCKIT_HOME/lib/tools.jar to
>> > $JROCKIT_HOME/jre/lib/ext/tools.jar fixed this problem. The reason
>> > this happened is probably because I chose *not* to use JRockit as my
>> > default JRE.
>> >
>> > Matt
>> >
>> > On 3/8/07, Matt Raible <[hidden email]> wrote:
>> >> Maybe I spoke too soon, it looks like there's issues using JRockit
>> >> with the native2ascii plugin:
>> >>
>> >> [ERROR] FATAL ERROR
>> >> [INFO]
>> >>
>> ------------------------------------------------------------------------
>> >> [INFO] Error starting Sun's native2ascii:
>> >> sun.tools.native2ascii.Main
>> >> [INFO]
>> >>
>> ------------------------------------------------------------------------
>> >> [INFO] Trace
>> >> Error starting Sun's native2ascii:
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
>>
>> >>
>> >> ava:67)
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
>>
>> >>
>> >> tive2Ascii.java:54)
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
>>
>> >>
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
>>
>> >>
>> >> at
>> >>
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
>>
>> >>
>> >> at
>> >>
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
>>
>> >>
>> >> at
>> >>
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
>>
>> >>
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
>>
>> >>
>> >> .java:539)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
>>
>> >>
>> >> ycleExecutor.java:480)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
>>
>> >>
>> >> java:459)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
>>
>> >>
>> >> ifecycleExecutor.java:311)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
>>
>> >>
>> >> xecutor.java:278)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
>>
>> >>
>> >> :143)
>> >> at
>> >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
>> >> at
>> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
>> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> >> at
>> >>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> >>
>> >> at
>> >>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> >>
>> >> at java.lang.reflect.Method.invoke(Method.java:585)
>> >> at
>> >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>> >> at
>> org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> >> at
>> >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>> >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> >> Caused by: java.lang.ClassNotFoundException:
>> sun.tools.native2ascii.Main
>> >> at java.lang.Class.forName0(Native Method)
>> >> at java.lang.Class.forName(Class.java:164)
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
>>
>> >>
>> >> ava:51)
>> >> ... 23 more
>> >> --- Nested Exception ---
>> >> java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
>> >> at java.lang.Class.forName0(Native Method)
>> >> at java.lang.Class.forName(Class.java:164)
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
>>
>> >>
>> >> ava:51)
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
>>
>> >>
>> >> tive2Ascii.java:54)
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
>>
>> >>
>> >> at
>> >>
>> org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
>>
>> >>
>> >> at
>> >>
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
>>
>> >>
>> >> at
>> >>
>> org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
>>
>> >>
>> >> at
>> >>
>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
>>
>> >>
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
>>
>> >>
>> >> .java:539)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
>>
>> >>
>> >> ycleExecutor.java:480)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
>>
>> >>
>> >> java:459)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
>>
>> >>
>> >> ifecycleExecutor.java:311)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
>>
>> >>
>> >> xecutor.java:278)
>> >> at
>> >>
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
>>
>> >>
>> >> :143)
>> >> at
>> >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
>> >> at
>> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
>> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> >> at
>> >>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> >>
>> >> at
>> >>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> >>
>> >> at java.lang.reflect.Method.invoke(Method.java:585)
>> >> at
>> >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>> >> at
>> org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> >> at
>> >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>> >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> >> [INFO]
>> >>
>> ------------------------------------------------------------------------
>> >> [INFO] Total time: 4 minutes 2 seconds
>> >> [INFO] Finished at: Thu Mar 08 11:34:49 MST 2007
>> >> [INFO] Final Memory: 226M/512M
>> >> [INFO]
>> >>
>> ------------------------------------------------------------------------
>> >> $
>> >>
>> >> On 3/8/07, Matt Raible <[hidden email]> wrote:
>> >> > JRockit in general seems to work great. I installed it about an
>> hour
>> >> > ago and did some testing. I was able to run "mvn jetty:run" and
>> >> > compile classes (to invoke a restart) about 15 times. I gave up
>> after
>> >> > that. With Sun's JDK 6, I get a PermGen error after reload #4.
>> >> >
>> >> > Summary: Use JRockit for developing AppFuse!
>> >> >
>> >> >
>> http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
>> >> >
>> >> > If you're developing an AppFuse 2.x-based application, please
>> download
>> >> > JRockit and try it out. I'll check back next week and see how it's
>> >> > going for everyone. If good, we'll change the download link to
>> >> > JRockit on the QuickStart Guide.
>> >> >
>> >> > Matt
>> >> >
>> >> > P.S. I don't think this means you have to use JRockit for
>> production,
>> >> > just when you're reloading a lot during development.
>> >> >
>> >> > On 3/8/07, Matt Raible <[hidden email]> wrote:
>> >> > > An XML snippet would be great. Do you think it's possible to
>> >> delegate
>> >> > > to one Sun JVM for testing and another for running? For example,
>> >> test
>> >> > > under JDK 5, run under JDK 6.
>> >> > >
>> >> > > Matt
>> >> > >
>> >> > > On 3/8/07, Philip Barlow <[hidden email]> wrote:
>> >> > > > Yes, exactly, surefire allows you to specify an independent JVM
>> >> for
>> >> > > > tests, separate to your deployment JVM. We use Suns JVM for
>> >> deployment
>> >> > > > and JRockit for tests now. the JVM can be declared in your POM
>> >> under the
>> >> > > > configuration for the surefire-plugin. If you need any more
>> >> info on this
>> >> > > > let me know.
>> >> > > >
>> >> > > > Matt Raible wrote:
>> >> > > > > Philip,
>> >> > > > >
>> >> > > > > What's your configuration for this look like? I'm assuming
>> >> you just
>> >> > > > > use JRockit for your tests, but you still use Sun's JVM
>> for "mvn
>> >> > > > > jetty:run"?
>> >> > > > >
>> >> > > > > Matt
>> >> > > > >
>> >> > > > > On 3/8/07, Philip Barlow <[hidden email]> 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 <[hidden email]> 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
>>
>> >>
>> >> > > > >>
>> >> > > > >> >>
>> >> > > > >> >> Sent from the AppFuse - User mailing list archive at
>> >> Nabble.com.
>> >> > > > >> >>
>> >> > > > >> >>
>> >> ---------------------------------------------------------------------
>> >> > > > >> >> To unsubscribe, e-mail:
>> >> [hidden email]
>> >> > > > >> >> For additional commands, e-mail:
>> >> [hidden email]
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > > > >> >
>> >> > > > >> >
>> >> > > > >>
>> >> > > > >>
>> >> ---------------------------------------------------------------------
>> >> > > > >> To unsubscribe, e-mail:
>> [hidden email]
>> >> > > > >> For additional commands, e-mail:
>> >> [hidden email]
>> >> > > > >>
>> >> > > > >>
>> >> > > > >
>> >> > > > >
>> >> > > >
>> >> > > >
>> >> ---------------------------------------------------------------------
>> >> > > > To unsubscribe, e-mail: [hidden email]
>> >> > > > For additional commands, e-mail:
>> [hidden email]
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > http://raibledesigns.com
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > http://raibledesigns.com
>> >> >
>> >>
>> >>
>> >> --
>> >> http://raibledesigns.com
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

wnqq

Re: mvn jetty:run => OutOfMemoryError: PermGen space

In reply to this post by wolrabp

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 <wnqq@yahoo.com> 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
>>

wolrabp

Re: mvn jetty:run => OutOfMemoryError: PermGen space

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

mraible

Re: mvn jetty:run => OutOfMemoryError: PermGen space

Administrator

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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Rob van Oostrum-2

Re: mvn jetty:run => OutOfMemoryError: PermGen space

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> http://raibledesigns.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

tibi

Re: mvn jetty:run => OutOfMemoryError: PermGen space

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> http://raibledesigns.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

tibi

Re: mvn jetty:run => OutOfMemoryError: PermGen space

and uh its on your own risk kill processes ;)

tibi

tibi wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>>
>>> --
>>> http://raibledesigns.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Nathan Anderson

Re: mvn jetty:run => OutOfMemoryError: PermGen space

In reply to this post by tibi

I just found a link that says MaxPermSize does not work as expected without PermSize also being set. They recommended settings like this"

-Xms256m -Xmx256m -XX:PermSize=256m -XX:MaxPermSize=256m

You could probably add the other -XX settings if they help.

Here's the link to the article:
http://www.unixville.com/~moazam/stories/2004/05/17/maxpermsizeAndHowItRelatesToTheOverallHeap.html

HTH,
Nathan

----- Original Message -----
From: "tibi" <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 1, 2007 2:16:04 AM (GMT-0800) America/Los_Angeles
Subject: Re: [appfuse-user] mvn jetty:run => OutOfMemoryError: PermGen space

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:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]