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 worry about. I will watch it to make sure it doesn't
keep growing until it reaches the tomcat thread limit, since the
server really isn't that busy.
I would assume that even with a request every second, only a small #
of established connections should be required to service the load.
Basically, the application is unused after 9PM, so I would expect the
# of established connections to be cleaned up as they are no longer
required.
Ian Long
Chief Software Architect, Opterus Inc.
On 5-Mar-09, at 1:38 PM, André Warnier wrote:
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
aborted or client network problems
[Thu Mar 05 10:34:08.878 2009] [25849:3086382864] [info]
ajp_service::jk_ajp_common.c (2186): (ajp13) sending request to
tomcat failed (unrecoverable), because of client write error
(attempt=1)
[Thu Mar 05 10:34:08.878 2009] [25849:3086382864] [info]
jk_handler::mod_jk.c (2357): Aborting connection for worker=ajp13
[Thu Mar 05 10:34:28.527 2009] [26222:3086382864] [info]
ajp_process_callback::jk_ajp_common.c (1603): Writing to client
aborted or client network problems
etc...
indicate, more often than not, simply that the connection with the
client was dropped (by the client or something else - but not the
server), before the server could send the response to the client's
request.
For instance, this happens when the user hits the cancel button in
the browser, or when the user gets impatient and starts clicking all
over before he gets the server response to his request.
If you are absolutely sure that neither of the above is the case
(e.g. you issue a request yourself, and patiently wait, and note
this message in the logs when it can only be due to your request,
then it /could/ indicate some network issue.
One such issue which I have experienced is some piece of software or
hardware between your browser and the server, dropping the
connection unilaterally, because for instance the connection was
idle more than xxx seconds.
But from the part of the server, it indicates with 100% certainty,
that the server was trying to send a response to the client, but no
longer could because the connection was no longer there.
In the absence of a cancel click or a click on another link, a
browser client will only "give up" after a request and close the
connection, after several minutes. That's when you get the kind of
message "This server does not respond, is maybe down, etc..".
HTH
(if only inasmuch as the above messages do not lead you into the
wrong path for the problem you are experiencing. Of course, a user
clicking on cancel or another link, could be the result of your
server really taking an inordinate amount of time to respond,
causing the user to get impatient...)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
