The 64.225.156.250 is the IP address that apache httpd and tomcat are
running on. To me it looks as if there is a 'default' host that those
'GET /' requests are being handled by. I assume
that VHost is the virtual host within tomcat that actually handled the
request, based on the definitio
On 06.03.2009 21:02, Ian Long wrote:
I have fixed the problem by stopping the https ping so that these stuck
processes don't happen, but am digging into the problem a bit further.
I think you are right that it's apache waiting for tomcat to send data
back for the request, because if I look at th
I have fixed the problem by stopping the https ping so that these
stuck processes don't happen, but am digging into the problem a bit
further.
I think you are right that it's apache waiting for tomcat to send data
back for the request, because if I look at the tomcat manager
application,
omcat and Apache with mod_jk
Here is some sample output from the system-status:
Srv PID Acc M CPU SS Req ConnChild
SlotClient VHost Request
0-0 20960/50/50 _ 0.0123 2 0.0 0.09
0.09X web1.opterus.com
I just took a subset of the list, the other few hundred processes were
also stuck in the same state. From the tomcat logs it looks like the
response has been sent back. I have seen cases where a firewall
doesn't recognize a connection has been closed.
On 5-Mar-09, at 7:05 PM, Rainer Jung
On 06.03.2009 00:44, Ian Long wrote:
Here is some sample output from the system-status:
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 2096 0/50/50 _ 0.01 23 2 0.0 0.09 0.09 X web1.opterus.com GET
/lbcheck.faces HTTP/1.0
1-0 2097 0/12/12 W 0.01 513 0 0.0 0.05 0.05 X web1.opter
Here is some sample output from the system-status:
Srv PID Acc M CPU SS Req ConnChild Slot
Client VHost Request
0-0 2096 0/50/50 _ 0.01 23 2 0.0 0.09 0.09 X web1.opterus.com GET /
lbcheck.faces HTTP/1.0
1-0 2097 0/12/12 W 0.01 513 0 0.0 0.05 0.05 X
BTW, I finally got this working. The final key was using the latest version
of tcnative binary. Note to others, make sure your code sets the
cache-control header to "no-transform, max-age=0".
buzzterrier wrote:
>
> Actually this may not be just a case of the end user clicking away. There
> is
On 05.03.2009 21:04, Ian Long wrote:
I haven't actually - I will turn it on and restart the server tonight.
Another thing that I find strange is the apache (using prefork MPM)
seems to keep increasing the number of child processes. For example,
when I run:
service httpd status
httpd (pid 31093
Actually this may not be just a case of the end user clicking away. There is
an Internet Explorer issue with downloading files, where IE deletes the
cached file before the user can load it. Your tomcat logs would probably
show an error like: ClientAbortException: java.io.IOException. I am
suffer
I haven't actually - I will turn it on and restart the server tonight.
Another thing that I find strange is the apache (using prefork MPM)
seems to keep increasing the number of child processes. For example,
when I run:
service httpd status
httpd (pid 31093 31055 31048 31047 31046 31045 31
Ok thanks. Based on monitoring, I don't think it's the server taking
a long time to respond, it's probably the users doing as you suggested
- I just wanted to make sure the log file entries weren't serious. I
want to make sure the rising established connection count isn't
something to wor
Ian Long wrote:
[...]
Hi Ian. I don't know about the load balancing part, but the following
errors :
I'm also seeing a few errors like the following in mod_jk.log:
[Thu Mar 05 10:34:08.878 2009] [25849:3086382864] [info]
ajp_process_callback::jk_ajp_common.c (1603): Writing to client aborte
Have you counted the actual # of requests for both apaches via something
like server-status, or looked in mod_jk.log, that they are both
receiving an equal # of successful requests?
The "Writing to client aborted or client network problems" are nothing
to really worry about. They usually mean the b
14 matches
Mail list logo
