I've attached your thread dump to this ticket:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=5030
Initially they weren't happy when I attached other people's thread dumps
to it because they were focused on solving my problem which was clearly
JDBC related. But, the ticket's description is "App server locks up
every few days. Could be application's fault", and I think it makes
sense to attach thread dumps from anyone who gets lockups that we can't
immediately explain.
Ryan
Ryan de Laplante wrote:
> I usually look for lines that start with httpWorkerThread, see what
> they are waiting on, then check those threads. They mostly show:
>
>> - waiting on <0x108c4f68> (a
>> com.sun.enterprise.web.connector.grizzly.LinkedListPipeline)
> I think that is normal. I did notice the selector threads have some
> locks, but this could be normal too:
>
>> "SelectorThread-80" prio=6 tid=0x317adc00 nid=0x4b0 runnable
>> [0x357cf000..0x357cfa98]
>> java.lang.Thread.State: RUNNABLE
>> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
>> at
>> sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
>>
>> at
>> sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
>>
>> at
>> sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
>> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
>> - locked <0x108c65f0> (a sun.nio.ch.Util$1)
>> - locked <0x108c65e0> (a java.util.Collections$UnmodifiableSet)
>> - locked <0x108c6568> (a sun.nio.ch.WindowsSelectorImpl)
>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
>> at
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.doSelect(SelectorThread.java:1337)
>>
>> at
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.startListener(SelectorThread.java:1284)
>>
>> - locked <0x108c6618> (a [Ljava.lang.Object;)
>> at
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.startEndpoint(SelectorThread.java:1247)
>>
>> at
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.run(SelectorThread.java:1223)
>>
> Beyond looking for things that look like my own thread dumps (http
> threads waiting on resource manager, resource manager waiting on JDBC
> driver, jdbc driver stuck), I don't know what the rest of this stuff
> means.
>
> I know Sun can only help non-paying-customers on best effort basis.
> Hopefully all of these people having lockups is serious enough for
> them to help all of them and fix GlassFish if it is a GlassFish
> problem. You're not the first I've seen getting lockups that appear
> unrelated to JDBC. I've talked with 2-3 people already who are
> planning on ditching GlassFish because of unexplained lockups that
> they don't get when using Tomcat, and they are unwilling to pay $4500
> to get help when they are just evaluating GlassFish to see if they
> want to switch over to it.
>
> Thanks,
> Ryan
>
>
>
> glassfish_at_javadesktop.org wrote:
>> Ryan,
>> 6 and a half hours this time, I've attached a JStack.. I forgot to
>> run the other stack trace.
>>
>> I changed the way fastpath works, but still get the same problem. I
>> was really hoping it was going to be the jdbc error...
>>
>> Do you know how to read JStack files? I'm just about to google it,
>> but if anyone has a recommendation on how to read them that will be
>> great...
>>
>> I look forward to your reply..
>> [Message sent by forum member 'adamburrett' (adamburrett)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=278931
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>