Not paying close attention, but you comment on 0 length recv caught my eye. I suspect the JHS code sees the 0 length recv and thinks that means more should be coming so does another recv and finally gets on with things when that timesout. Perhaps the 0 length recv needs to be treated as the end of the request.
But the puzzle is that these are ajax post requests and they should all be driven by content length and the request should only be ready for processing when all the data has been received. It would be interesting in your logging data to determine which recv in core.ijs getdata is timing out. The first loop is to get the header and content length. The second loop is to get the rest of the data driven by content length. Thanks for digging into this problem! On Tue, Jan 24, 2012 at 9:03 AM, David Mitchell <[email protected]>wrote: > Currently, I am looking at the following sequence (the log below is part > of a > larger sequence). It shows IE9 receiving the initial JHS page from > jconsole/jhs > as a sequence of non-zero recv's. Then, IE9 gets a 0 length recv and > closes the > socket. The next response is the jconsole/jhs report of a recv timeout. > > The doc I can find indicates that a zero-length receive can be treated as a > client request to have the server close the socket. > > --- > > 23 10 54819 send: 1: Process 0xFFFFFA8006416920, Endpoint > 0xFFFFFA8004566C30, > ... > Buffer Count 1, Buffer 0xFFFFFA8005BC72F8, Length 41191, Seq 3024, Status > 0x0 > 23 10 54860 recv: 0: Process 0xFFFFFA8005CCD060, Endpoint > 0xFFFFFA8004590E30, > Buffer Count 1, Buffer 0xFFFFFA800240F990, Length 8192, Seq 4107, Status > 0x0 > > 23 10 54869 recv: 1: Process 0xFFFFFA8005CCD060, Endpoint > 0xFFFFFA8004590E30, > Buffer Count 1, Buffer 0xFFFFFA800240F990, Length 0, Seq 4110, Status 0x0 > > 23 10 54873 socket cleanup: 0: Process 0xFFFFFA8005CCD060, Endpoint > 0xFFFFFA8004590E30, Seq 2002, Status 0x0 > > 23 10 54879 disconnect indicated: 3: Process 0xFFFFFA8006416920, Endpoint > 0xFFFFFA8004566C30, Seq 12000 > > 23 10 54883 socket cleanup: 1: Process 0xFFFFFA8005CCD060, Endpoint > 0xFFFFFA8004590E30, Seq 2003, Status 0x0 > > 23 10 54884 closesocket: 0: Process 0xFFFFFA8005CCD060, Endpoint > 0xFFFFFA8004590E30, Seq 2000, Status 0x0 > > 23 10 54884 closesocket: 1: Process 0xFFFFFA8005CCD060, Endpoint > 0xFFFFFA8004590E30, Seq 2001, Status 0x0 > > 23 13 50718 2012 1 24 7 23 13 527 jhs : recv timeout > > > > On 1/23/2012 21:33, bill lam wrote: > > I do not use IE9 and cannot debug it. A HTTP GET needs not including a > > count in its header, so jhs will wait until the remote side close the > > socket, if IE9 doesn't, then it will only close by timeout. A possible > > solution is to check the presence of two consecutive newline and the > absent > > of content-length count as a condition to close socket without waiting > any > > further. > > > > untested and just a wild guess. > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
