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
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 sol
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 wi