Thanks for the information...
In our mod_jk log we have the following showing up:
[Wed Jan 25 13:21:33 2006] [jk_ajp_common.c (1401)]: ERROR: Receiving
from tomcat failed, recoverable operation. err=1
[Wed Jan 25 13:21:33 2006] [jk_ajp_common.c (836)]:
ajp_connection_tcp_get_message: Error - Wrong message format 0x4854
[Wed Jan 25 13:21:33 2006] [jk_ajp_common.c (1248)]: Error reading
reply from tomcat. Tomcat is down or network problems.
[Wed Jan 25 13:21:33 2006] [jk_ajp_common.c (1401)]: ERROR: Receiving
from tomcat failed, recoverable operation. err=2
[Wed Jan 25 13:21:33 2006] [jk_ajp_common.c (1429)]: Error connecting
to tomcat. Tomcat is probably not started or is listening on the wrong
port. worker=ajp13 failed errno = 11
That's after it actually works a few times, so Tomcat is definitely
running and accessible (thru port 8080 also).
In error log there a lot of processes that haven't exited, here is some
information from it when we actually do a restart:
start[Thu Jan 26 10:31:24 2006] [warn] child process 5805 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 5806 still did not exit,
sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 6668 still did not exit,
sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 28585 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 13921 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 27065 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 13928 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 27152 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 18708 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:24 2006] [warn] child process 18714 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 5805 still did not exit,
sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 5806 still did not exit,
sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 6668 still did not exit,
sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 28585 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 13921 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 27065 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 13928 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 27152 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 18708 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:25 2006] [warn] child process 18714 still did not
exit, sending a SIGTERM
[Thu Jan 26 10:31:26 2006] [notice] caught SIGTERM, shutting down
[Thu Jan 26 10:31:31 2006] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Thu Jan 26 10:31:31 2006] [notice] Digest: generating secret for digest
authentication ...
[Thu Jan 26 10:31:31 2006] [notice] Digest: done
[Thu Jan 26 10:31:32 2006] [notice] Apache/2.0.40 (Red Hat Linux)
configured -- resuming normal operations
I don't believe it's our browser, we can actually reopen a new browser
and it won't work right also (if we do it around the same time). I'm
going to check the mod_jk file again and make 100% sure it's compatable
with our versions of Tomcat and Apache. Do you think this could be
causing the problem possibly? Any other suggestions would be great,
Thanks again.
Adrian Nadeau
VP, Development
Evolving Solutions...Technology for changing
[EMAIL PROTECTED]
www.evolvingsolutions.ca
506.633.2012
Jonathan Woods wrote:
Adrian -
I haven't met this problem, but a few things occurred to me after reading
your message:
1. Don't forgot you could probably (depending on your config) always use
mod_proxy instead of mod_jk, just as a temporary measure.
2. Sometimes browsers are set to have only 2 or 3 concurrent connections
open to a server. Maybe something about your config - e.g. the resources
being served up, or a mod_jk problem - means that the connections aren't
properly closed, so on the third click it's actually your browser waiting
until the other connections are closed.
3. It also sounds like a threading problem could cause these symptoms. Is
there any 2- or 3-ness about the Tomcat config - e.g. the size of the pool
of servlet instances maintained? Are the resources you're reaching when you
click threadsafe?
4. Try looking in Apache's error log and in mod_jk's log (assuming you
write one - JkLogFile directive).
Jon
-----Original Message-----
From: Adrian Nadeau [mailto:[EMAIL PROTECTED]
Sent: 26 January 2006 14:56
To: users@tomcat.apache.org
Subject: Tomcat and mod_jk question on Red Hat 9
Hello,
We recently setup mod_jk on a server running Red Hat 9. We are having some
odd problems with the new setup. For some reason, everything works fine for
the first 2 clicks when testing the process (running the examples webapp
thru Apache 2.0.40). However, when we click something (anything, doesn't
have to be the same steps) for the third time, it seems as though mod_jk
cannot connect through AJP13 (Tomcat version is
4.1.29) . It trys to load for a long time and then nothing loads. If we
wait for a bit and then do the same test again, the same thing happens.
I can post more information and config settings, but I wanted to see if this
is a common problem or not? We've had no problems running mod_jk in a
Windows environment or Solaris in the past. If we need to post more
information that is not a problem, we can do that. We talked to our hosting
provider and they seem to think it's that we are running out of TCP Sockets?
Any information would be great as we are trying to get a number of
applications running on the server ASAP (of course). Thanks!
Regards,
Adrian Nadeau
VP, Development
Evolving Solutions...Technology for changing [EMAIL PROTECTED]
www.evolvingsolutions.ca
506.633.2012
---------------------------------------------------------------------
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]
