Hello; I would agree with you except...
I switched back to the release version Friday afternoon and the size of the logfile since then has been 0 bytes - nothing. I will leave it this way until Wednesday evening and then switch back to the new one again for a day to see what happens. Thanks - dave David Thielen www.windwardreports.com 303-499-2544 -----Original Message----- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 4:26 PM To: Tomcat Users List Subject: Re: New isapi_redirect.dll has problems David, I have taken some time to look through the information you have provided and have come to the conclusion that there are 2 issues here. The first is the connection errors of the form: [Mon Feb 13 07:56:51 2006] [info] jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=3 [Mon Feb 13 07:56:51 2006] [error] jk_ajp_common.c (1758): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=ajp13w failed Looking at the more detailed log file you placed in the zip file, this looks like it only happens just after IIS is started/restarted. Can you confirm this? What state is Tomcat in at this time? If Tomcat has been restarted as well, it is possible that Tomcat isn't quite ready to serve requests. The second is the warnings of the form: [Mon Feb 13 17:27:46 2006] [warn] jk_uri_worker_map.c (429): Uri http://www.enemynations.com is invalid. Uri must start with / The more I look at this, the more I think that these messages are caused by a misbehaving robot. My reasons for thinking this are: - The requests come in very quick succession, far faster than a normal user would navigate - The http in the url. JK basically does: if (host.length() >0) { searchUri = "/" + host + "/" + requestUri } else { searchUri = requestUri } There is nowhere I can see where the protocol could get added to the start of the URI. Additionally, I have also checked through every conditional debug log call in JK and there are a few places where it does more than just make a logging call but all are explainable and none have any impact on what IIS logs. I need to do some testing to confirm how IIS behaves if URLs that do not map to workers are requested. This might lead to an explanation of why some these odd requests are not logged in IIS. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]