On 12.11.2009 23:35, ndunn1979 wrote: > > > Rainer Jung-3 wrote: >> >> Does it happen every time for that page? Or is it at least easily >> reproducible for you? Does the "load not completely" always stop at the >> same position? If yes, which byte offset? >> >> Thos questions help us decide, how easily we will be able to attack the >> prpblem. >> > > The issue is reproducible and it seems to happen at the same place. The log
Good. > doesn't make it clear what byte offset it's failing at. I don't know if this One would normally check this at the client/browser, e.g. using Firefox and the Firebug plugin you can look at what exactly was received. > is normal for the mod_jk log file, but even for the parts that come through > clean it doesn't display all of the binary data. debug logs only the first part of each AJP packet, trace will log the full packets. > I see the request headers and the response headers come through clean. Then > I see this: > > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] jk_ajp_common.c (1259): > received from ajp13 pos=0 len=8188 max=65536 > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] jk_ajp_common.c (1259): > 0000 03 1F F8 0A 0A 0A 3C 68 74 6D 6C 3E 0A 3C 68 65 - ......<html>.<he > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] jk_ajp_common.c (1259): > 0010 61 64 3E 0A 3C 74 69 74 6C 65 3E 4D 6F 64 69 66 - ad>.<title>Modif > > Then I see some of the data, then I see: > > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] jk_ajp_common.c (1259): > 03f0 65 6D 54 79 70 65 3C 62 72 3E 41 43 42 6F 6E 75 - emType<br>ACBonu > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] mod_jk.c (506): written > 8184 out of 8184 > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] jk_ajp_common.c (1259): > received from ajp13 pos=0 len=8188 max=65536 > [Thu Nov 12 16:44:19.937 2009] [4604:4760] [debug] jk_ajp_common.c (1259): > 0000 03 1F F8 0A 3C 74 64 3E 3C 69 6E 70 75 74 20 74 - ....<td><input.t > > At this point, I can see that the end of the first block doesn't match up > with the beginning of the next block. But I figure this must be okay because > this part of the final document being sent to the browser has no issues. Guess that's the log output truncation be debug. > The first issue doesn't show up until byte 266507 (in the final html saved > to a text file). > > The next 137514 bytes are repeated two or three times and the file never > finishes. Now we would want to find out, whether that repeted data is actually send by the backend or not. > The byte offsets are probably skewed because the browser seems to be > correcting the malformed html. I don't know how to get a more precise byte > offset because all it ever says is "written 8184 out of 8184" and "pos=0 > len=8188 max=65536" for each block it logs out. Is there an even more > detailed log level? The 8184 refers to the AJP default max packet size of 8KB minus some protocol overhead. So if a bug response is send, you will see lots of thosse 8184, which are simply fully sized AJP packets. Although you tried to increase the max packet size, it won't probably work, because the backend has to be reconfigured to. Anyhow, the max packet size should have no relation to the problem. As said: "JkLogLevel trace" will log the full packets. Regards, Rainer > Rainer Jung-3 wrote: >> >> >> Which part of the log of the one request is it? Is it a full excerpt >> from the end of the request, or are there lines between those shown >> missing? >> > > The log I posted originally was from the end of the request. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
