You might find this information helpful, even if you aren't using a
Microsoft JDBC driver:
http://www.ryandelaplante.com/rdelaplante/entry/glassfish_lockups_were_microsoft_s
Start by capturing a thread dump when it locks up and determine if all 5
Grizzly worker threads are blocked, and what is blocking them. Probably
something related to database.
Ryan
glassfish_at_javadesktop.org wrote:
> Hallo!
> We are using glassfish v2 ur1 on our production Debian systems.
>
> Under certain circumstances the container stops responding to request.
>
> * In one standalone container are timer trigger JDBC batch inserts (injected data source), up to 800 a second. (2 million inserts a day)
> * There are some SELECTS to this data with small result sets.
> * All beans are SLSBs with bean managed transactions.
> * The kemp load balancer says there are 6-10 http request a second, and 120 'active connections'
>
> * In a other container there are very large JDBC Select (large result set), which is read through JDBC with a cursored result set.
> * During reading the large result set for some time, the container stop responding to any http-request.
> * [b]There is no error message in the Log file, just a plain old crash.[/b]
> * The only awkward thing i'm aware of, are many entries of "in transaction" in my 'select * from pg_stat_activity' (they are there for only one moment, and i'm not aware of having in transactions, bean managed transactions, but never opening one)
>
>
> Where is a place to narrow down this error? Where should I look at?
> May the container run out of open file handles?
> Any educated guess?
>
> Thanks a lot.
>
> Stephan
> [Message sent by forum member 'iceandfire' (iceandfire)]
>
> http://forums.java.net/jive/thread.jspa?messageID=334668
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>