The 0 length recv is within IE9 at the end of receiving the initial jhs page.
The recv timeout is in jconsole/jhs. When I look at the same logging for Firefox, I see that Firefox also gets a final 0 length recv for the initial jhs http data, but Firefox then immediately did a 1 byte send, which IE did not do. Both IE and Firefox sent this to jconsole/JHS as the initial request: jhs sentence: jev_get_jijx_'' URL=jijx The second input that jconsole/JHS got from IE9 was: jhs sentence: jev_jijx_ 0 URL=jijx The second input that jconsole/JHS got from firefox was: jhs sentence: jev_get_jfilesrc_ URL_jhs_ URL=favicon.ico On 1/24/2012 9:34, Eric Iverson wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
