JNeuhoff wrote:
> Yes, it starts out with a much smaller memory, around 10 to 15 MB or so,
> even after a few initial connections to Tomcat from one user session.
>
I see, any idea, how the delta 70-15=55MB relates to connections (if you
do stress tests with real parallelity e.g. 20, 50, 100, 200, how does
memory behave after stopping the load)?
> I just downloaded the file (of the same name) from another mirror, and this
> time it is really version 1.2.20, looks like the other mirror was corrupted
> (same file name, old version).
No idea why, it's good you observed it.
> Anyway, I made another interesting observation for both mod_jk 1.2.10 and
> 1.2.20: When I hammer my website rapidly with requests, by clicking too
> quickly in my web browser on links within the same site, mod_jk eventually
> becomes unable to receive responses from Tomcat, causing Apache2 to come
> with standard Error 503 replies. I was using the workers.properties with
> this:
>
> # Define 1 real worker using ajp13
> worker.list=ajp13
> # Set properties for worker1 (ajp13)
> worker.ajp13.type=ajp13
> worker.ajp13.host=localhost
> worker.ajp13.port=8009
> worker.ajp13.connection_pool_timeout=600
> worker.ajp13.connection_pool_minsize=10
> worker.ajp13.connect_timeout=15000
> worker.ajp13.prepost_timeout=10000
>
> And only mod_jk.log had some error messages, first in increasing numbers
> something like this:
>
> ....
> [Thu Jan 18 17:10:20 2007] [3336:0792] [info] jk_ajp_common.c (1410):
> Writing to client aborted or client network problems
> [Thu Jan 18 17:10:20 2007] [3336:0792] [info] jk_ajp_common.c (1795):
> (ajp13) request failed, because of client write error without recovery in
> send loop attempt=0
> ....
These ones are OK, they are info level and they only tell you, that when
mod_jk tried to send back answers, it found out, that the browser
already closed the connection. That's true, because every reload during
waiting for response in the browser will reset the browser connection to
the web server. This will only be detected, when mod_jk tries to use the
connection to either read parts of the request (this normally already
succeeded when you did the reload) or it tries to write back parts of
the result.
> and finally more and more of the
>
> ....
> [Thu Jan 18 17:10:59 2007] [3336:0188] [info] mod_jk.c (2063): Service
> error=0 for worker=ajp13
> [Thu Jan 18 17:11:00 2007] [3336:1368] [error] jk_ajp_common.c (1015):
> (ajp13) can't receive the response message from tomcat, network problems or
> tomcat (127.0.0.1:8009) is down -53
> [Thu Jan 18 17:11:00 2007] [3336:1368] [error] jk_ajp_common.c (1536):
> (ajp13) Tomcat is down or refused connection. No response has been sent to
> the client (yet)
> [Thu Jan 18 17:11:00 2007] [3336:1368] [info] jk_ajp_common.c (1828):
> (ajp13) receiving from tomcat failed, recoverable operation attempt=0
> [Thu Jan 18 17:11:00 2007] [3336:1368] [info] jk_ajp_common.c (1867):
> (ajp13) sending request to tomcat failed, recoverable operation attempt=1
> [Thu Jan 18 17:11:00 2007] [3336:0216] [error] jk_ajp_common.c (947):
> (ajp13) can't receive the response message from tomcat, network problems or
> tomcat is down (127.0.0.1:8009), err=-53
> [Thu Jan 18 17:11:00 2007] [3336:0216] [error] jk_ajp_common.c (1562):
> (ajp13) Tomcat is down or network problems. Part of the response has already
> been sent to the client
> [Thu Jan 18 17:11:00 2007] [3336:0216] [info] jk_ajp_common.c (1828):
> (ajp13) receiving from tomcat failed, recoverable operation attempt=1
> [Thu Jan 18 17:11:00 2007] [3336:0216] [info] jk_ajp_common.c (1867):
> (ajp13) sending request to tomcat failed, recoverable operation attempt=2
> [Thu Jan 18 17:11:00 2007] [3336:0216] [error] jk_ajp_common.c (1879):
> (ajp13) Connecting to tomcat failed. Tomcat is probably not started or is
> listening on the wrong port
> ....
>
Those err=-53 are bad, 53 on Windows is connection aborted. You should
find something about them in the tomcat logs.
> Only a server re-boot cleared up the connections (there were only 2 of them
> established).
>
> Is it possible that mod_jk can't cope with queueing too many rapidly
> incoming requests? Admittedly, this doesn't happen from normal users, but a
> malicious person would be able to bring down the web service this way. Are
> there preventitive settings for this scenario?
It's not really a problem of rapidly incoming, but you demand more
throughput, than the system can provide. If you click 100 times a second
(not waiting for replies) and your system can only deliver 50 responses
per second, then you will queue up unfinished requests (50 after 1
second, 100 after 2, 150 after 3 etc.) Each unfinished request needs a
separate Thread in Apache and in Tomcat, o since you only provide 250 of
them, you can saturate the system quite fast (again assuming your
throughput is lower than the request injection rate).
If you want to prevent denial of service, you need to do that on a low
protocol level. There are a couple of Apache modules, but more likely
you'll use some sort of security appliance. But that would be better
discussed in a separate mail thread.
Your statement about 2 connections left but nevertheless a server reboot
was needed is unclear to me. I would expect, that at most a tomcat
restart would be needed. Could be, that you'll find an OutOfMemoryError
in your tomcat logs (because of the huge amount of parallel unfinished
requests), which might have sent tomcat to an undefined state.
>
> Regards
>
> J.Neuhoff
>
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
