Baba wrote:
...
Is there no way to get this information (How much requests are in the
accept queue?) out?
Even if you could find this out at the Tomcat level, I seem to recall
that you also wanted to find out "what kind of request" these were, so
that you could decide to reject selectively some of them.
I do not think that there is ever going to be a way by which you can do
that.
So I would look at another solution :
In front of your Tomcat, have another front-end server, which can really
examine the requests /before/ forwarding them to Tomcat.
This server may also be able to find out how many threads are currently
busy processing requests at the Tomcat level, and based on these two
aspects, decide to forward or not the request to Tomcat.
The front-end may even be able then, in case it rejects a request, to
return a nice answer to the client, instead of just aborting the connection.
You can probably achieve about the same effect in Tomcat alone, along
the following lines :
- have all client requests always go to a specific "dispatcher" webapp
- that webapp examines the situation, and depending on it either
forwards the request to a "real" webapp, or rejects the request and
returns something itself to the client.
The bottleneck then becomes this dispatcher webapp, but if it is
lightweight enough, that might work too.
But I still believe the front-end solution would be more flexible and
scalable.
After all, that is very close to what a load-balancer does.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
