Mladen Turk wrote:
I'm not an expert, but speaking about security issue, it is not dangerous to have a DOS attack by adding infinitly sockets to the queue? How long the queue will be? How will you handle connection that has been resetted in the queue? Will they reach Tomcat?One more... Here is the scenario: If TC instance is too busy or reached the connection limit the next connection is refused, causing entire worker to switch to the error state. This isn't very smart (at least for threaded servers). I propose that we use the apr_queue to solve that. The socket will be pushed to the queue, when successfully connected, and pop when finished. If we reach the connection limit the next one will block until the any of the active one finishes (releasing space in the queue). Also, if the connection is refused and we have some sockets in the queue (meaning the TC is busy responding), we'll block untill the connection is accomplished or timed-out.
My concern is by adding another "waiting room", we are just incresing the number of connection Tomcat can handle. So why not increasing the connection limit or just add the queue mechanism directly in Tomcat connectors?
IMBW...you are the expert :-)
-- Jeanfrancois
If there is a connection error caused by the TC's fault, the returned
error from freed one will cause the entire worker to go to the error
state.
Thoughts?
MT.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
