Mark H. Wood wrote:
On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov]
Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
So you are saying it could be possible to know in advance that certain
requests are for repeated requests of nothing or being made by a bot,
versus regular legitimate requests, in order to move those bot requests
off to another thread?
Nothing of the sort. You simply put each 404 response on queue, and have an
existing timer thread send it out when the appropriate delay has been achieved.
No threads are tied up during the delaying action.
However, sockets *are* tied up. We don't get this benefit for free;
it costs both kernel and application memory. Even if the limits on
these are infinitely adjustable, we might not want to adjust them that
high because they are doing another job for us.
True, but returning a 404 is something that needs to be done anyway, for legitimate
requests as well as for the bots.
As a matter of fact, returning any of the 4xx or 5xx error codes, which are fairly
"standard" things (by which I mean that in most cases, the returned message is the same,
no matter which application sends it and no matter what the request was).
So why tie up a really valuable application thread to do that ?
If any application, once it is determined that such an error message has to be sent back,
could offload the actual work of doing it to some less-valuable process/logic, might this
not be of general benefit to the server ?
In such a case, the special handling of a 404 with an additional delay (or not), would
only be a marginal thing.
It is dangerous to make assumptions like this without actually testing it in the real
world, with a real server submitted to a real load. And I understand that this would
require someone to actually make the changes in the server code (I don't have the skills
to do that). On the other hand, without actually testing it, we will never know.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
