Hello,
as usual I'd start from looking at the thread dump, when you start
see, that GF is unresponsive.
1) ps -A | grep java
to find GF pid
2) kill -3 pid
After that you have the dump in the jvm.log file, please send it.
Thanks.
WBR,
Alexey.
On Mar 19, 2010, at 2:27 , glassfish_at_javadesktop.org wrote:
> Hello Jean-Francois,
> We recently experienced the same problem 2x and we gained further
> insights on the issue plus have further questions which I hope you
> might have an answer.
> To respond to your question from 04/15/2009:
> - you can offload the session by storing the data inside a database:
> => unfortunately that will require change in the application and
> that's not feasible.
> - you using some HA solution?
> => no, we are not.
>
> We are still on GF v2.1 + JDK1.5.0_22 + Solaris.
> What we recently found is CLOSE_WAIT condition occurs when GF
> receives TCP packet w/ receiving window size set to 0.
> Our application interfaces w/ a 3rd party product and time to time,
> this product sends TCP packet w/ window size = 0 to GF. We
> understand that that's not an expected client (request sender)
> behavior from GF's perspective but we wanted to know how GF
> (Grizzly) handles such unexpected condition. For what we observed,
> as GF receives such packets, it eventurally becomes unresponsive.
> How is GF handling such situation in order to avoid deadlock? How
> long will it wait before it sends new packet to client so to prompt
> for new window size?
> I hope the question make sense to you...
> Your assistance will be greatly appreciated.
> Best regards
> [Message sent by forum member 'ur_afroinu']
>
> http://forums.java.net/jive/thread.jspa?messageID=392662
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>