[proposal] add the apr_queue mechanism to apr_socket

[Mladen Turk <mt...@mappingsoft.com>]

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.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [proposal] add the apr_queue mechanism to apr_socket

[Costin Manolache <cm...@yahoo.com>]

Mladen Turk wrote:

> 
> 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.

Alternative solution: 

When ( connection_limit - 1 )  is reached, we send back a special response
code ( OVERLOADED ). Same could be sent if the worker uptime is higher 
than a certain limit ( if you implement the other proposal ).

The response code will not put the worker in error state, just move it to
the end of the queue. If all worker are overloaded, we'll just inform the
user.

Regardless of the solution you choose - I don't think you should block,
or at least you should have an option that will switch to the next
worker or return a message. It's far better to get a page displaying
a progress bar or telling to try later - instead of the "hunged" feeling.


Costin


> 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [proposal] add the apr_queue mechanism to apr_socket

[Jeanfrancois Arcand <jf...@apache.org>]

Mladen Turk wrote:

>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.
>
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?

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>