Damien Corbishley wrote:
Hi,
I'm getting stuck with an error we are seeing on our production
server under load.
We upgraded our combination of Apache,Tomcat,Java all running on
Solaris 10 to
Apache 2_2.0.55.build2
This doesn't sound like a real Apache httpd version. You can check the
real version with "httpd -V" or when using log level info in the error
log of httpd.
Worker or prefork MPM?
Tomcat 5.5.23
Java 1.5.0_06-b05
If you are in a general update situation, switch to 1.5.0_12 or whatever
seems to be recent and not only a couple days old.
And finally mod_jk-version?
Our Apache Tomcat connector is AJP/1.3.
What's the configuration of the connector element in server.xml?
It's all installed on the same server, we have no tomcat clusters and
no load balancers.
With a few (10) concurrent users accessing the various JSP's
everything worked as expected, all our functional tests passed.
We opened more up live traffic to the server and starting seeing the
following error message:
[Thu Sep 06 02:23:00 2007] [error] ajp_service::jk_ajp_common.c
(1758): Error connecting to tomcat. Tomcat is probably not started or
is listening on the wrong port. worker=worker1 failed
Is Tomcat on the same machine, or on another one?
What do you get for "netstat -an| grep TOMCATPORT" where you replace
TOMCATPORT with the port number your Tomcat AJP connector listens on?
How many ESTABLISHED, how many of other states (SYN_SENT, CLOSE_WAIT etc.)?
What's you mod_jk configuration?
On the client side this was being reported as a 503 and our
"intelligent" browser was re-submitting the request and generally,
on the second time, the request would be successful.
After an hour we then had a Solaris panic, and after analyzing the
crash using scat I can see that the cause was:
Solaris panic looks very bad. I would definitely open a bug with sun.
I'm not saying that the original problem is there, but it is very
unusual, that the whole system panics.
panic string: BAD TRAP: type=9 rp=2a1015332d0 addr=0 mmu_fsr=0
and looking further into the trap, it seems to be network related.
<trap>ip:tcp_conn_request+0x894 (0x4, 0x2000, 0x136ec00,
0x3a2b9a44040, 0x40e03960300, 0x40dedc247c0)
ip:squeue_drain+0xe4 (0x300015ddec0, 0x40e2021c1c0, 0x411666de,
0x135f2c0, 0x3a2b9a44040, 0x3)
ip:squeue_enter+0x358 (0x300015ddec0, 0x38fca5e0d80, 0x3000426b640,
0x3a2bd674c00, 0x0, 0x1)
ip:tcp_wput - frame recycled
I am still trying to work out if the crash is a symptom of the
browsers resubmitting the failed requests and we've hit a Solaris bug
that we haven't got a patch for,
Or if the two errors are unrelated and it was coincidence that we
panicked whilst having mod_jk errors.
Any help/pointers in resolving the mod_jk error would be appreciated,
I included the brief crash information as it may be relevant.
Thanks
Damien
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
