Thanks for the clarification on the initial heap size. I've set both Xms and Xmx to 512m for the following test.

I was able to reproduce the problem immediately with:
- Xms and Xmx both set to 512m
- Java 1.6 with no JPDA running
- XX:+PrintGCDetails enabled

I've attached the thread dump which I took on the 3rd or 4th attempt after the process hung. They were all the same on each measure.

I've also attached the catalina.out log which shows the GC basically freezing.

One thing that it is a little odd is that the Catalina log is basically in the middle of (or possibly JUST finished) some kind of hibernate initialization but the blocked thread (the only thread doing anything but sleeping) doesn't really indicate this.

- Bradley

On Mon, Aug 31, 2009 at 6:19 PM, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
Hello,
This indeed sounds like you have problems with one of the spaces,
please add following option to the JAVA_OPTS (or whatever you are
using) to seubmit jvm parameters:
-XX:+PrintGCDetails

And, no tomcat's initial heap size don't default to 64Mb. The JVM
allocateds a heap dependent on your computer type, for example the 1.5
VM would identify a 2 core 2 GB machine as 'server' and allocated more
memory than with 1 core cpu.

http://72.5.124.55/docs/hotspot/gc5.0/ergo5.html

regards
Leon

P.S. I know the link looks strange it come ups from google:
http://www.google.de/search?q=hotspot+memory+ergonomics&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

P.P.S I had a similar situation once, as a client had set space sizes
manually (new and old) and the old space was full. The VM was only
full garbage collecting which led to 100% CPU usage and strange thread
dumps. The above option would help you in this case to identify the
full gc runs previously and during the hangup.



On Mon, Aug 31, 2009 at 11:34 PM, Bradley
Wagner<bradley.wagner@hannonhill.com> wrote:
>>
>> The other interesting point is that all of those are hung in places where
>
> they would naturally be allocating an object or have very recently allocated
>
> an object, and the JVM *might* in theory be growing the heap.  Bradley, are
>
> your initial and maximum heap sizes identical (I suspect not from your
>
> original message)?  If not, what happens if you make them so?
>
>
> From my original post, I'm setting the following memory parameters:
>
> -Xmx512M -XX:MaxPermSize=128m
>
> so I'm not setting an initial heap size at all. If I remember correctly,
> Tomcat's initial heap size default's to 64MB or something.
>
> I'll try to set the initial and max to the same to see if that has any
> effect.
>
> Thanks,
> Bradley
>
> On Mon, Aug 31, 2009 at 4:59 PM, Peter Crowther <peter.crowther@melandra.com
>> wrote:
>
>> 2009/8/31 Christopher Schultz <chris@christopherschultz.net>
>>
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Bradley,
>> >
>> > On 8/31/2009 4:02 PM, Bradley Wagner wrote:
>> > > Sorry, I should have mentioned this before, but in all cases I tried
>> the
>> > > thread dumps 2-3 times at least 30s apart and none of the threads have
>> > > progressed at all.
>> >
>> > I agree with Mark: the three threads you showed were different
>> > (different ids), and showing different call stacks. Are you saying that
>> > each thread dump you took represents multiple thread dumps where that
>> > particular thread didn't progress /at all/ over your multi-dump sample?
>> >
>> > You might even want to run strace to see which library function calls
>> > are actually completing.
>> >
>>
>> Agree.
>>
>> The other interesting point is that all of those are hung in places where
>> they would naturally be allocating an object or have very recently
>> allocated
>> an object, and the JVM *might* in theory be growing the heap.  Bradley, are
>> your initial and maximum heap sizes identical (I suspect not from your
>> original message)?  If not, what happens if you make them so?
>>
>> - Peter
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org