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