It was determined that there is not a problem with GlassFish. Either
the application code or one of its dependencies (such as a JDBC driver)
is locking the grizzly worker thread. Once all five worker threads are
locked up you experience a lockup. When you experience a lockup, run the
following command:
asadmin generate-jvm-report --type=thread > thread_dump.txt
Examine the file for blocked threads and see what they are waiting on.
The file is basically a stack dump for each thread. That is how I found
what was locking my application and fixed it.
A second lockup I recently encountered was also my fault. My app was
executing an SQL query with no WHERE clause on a many gigabyte sized
database table. It took two months to figure out what was happening.
JPA caches every entity it loads by default, and never expires them. I
disabled JPA caching and fixed the query to not allow it to return many
gigabytes of results.
Ryan
glassfish_at_javadesktop.org wrote:
> Hi,
>
> Did this problem ever get resolved? I have run into the exact same problem as Ronald with my GlassFish server. -Dcom.sun.enterprise.server.ss.ASQuickStartup=false is set and ulimit for file descriptors is 1024.
>
> peppeme in this thread http://forums.java.net/jive/message.jspa?messageID=286954#286954 suggested to raise ulimit to 65536, but I doubt that should help. It should only delay the problem because something, either glassfish or the domain running on it must be leaking file descriptors it seem.
>
> If patches exist, has they been integrated into GlassFish or do you need a support contract for that?
> [Message sent by forum member 'bjourne' (bjourne)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328160
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>