Scott Marlow wrote:
Anyway, my point is that this could be a worthwhile enhancement for
applications that run on Tomcat. What I don't understand yet is whether
the same functionality is already in Tomcat.
I should point out that some applications shouldn't limit the max number
of concurrent requests (long running requests won't benefit but maybe
those applications shouldn't run on the web tier anyway :-)
I agree with the intent, but this is not implemented properly. I think
the idea is to restrict concurrency in the application layer, rather at
the low level (where, AFIK, concurrency isn't that expensive, and is
better addressed using a little non blocking IO). The performance
benefits for certain types of applications will be the same, but without
introducing any unwanted limitations or incorrect behavior at the
connector level.
I think you should write a ConcurrencyValve instead, which would do
something like:
boolean shouldRelease = false;
try {
concurrencySemaphore.acquire();
shouldRelease = true;
getNext().invoke(request, response);
} finally {
if (shouldRelease)
concurrencySemaphore.release();
}
As it is a valve, you can set it globally, on a host, or on an
individual webapp, allowing to control concurrency in a fine grained
way. In theory, you can also add it on individual servlets, but it
requires some hacking. Since it's optional and independent, I think it
is acceptable to use Java 5 for it.
As you pointed out, some applications may run horribly with this (slow
upload is the most glaring example).
RÃmy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
