Dossy Shiobara schrieb:
On 2007.10.13, Tom Jackson <[EMAIL PROTECTED]> wrote:
This all looks great, except for the fact that the NsRunAtReadyProcs
proc is never called.
But, you're absolutely right: we need to figure this out, one way or
another. Thanks for finding this.
The question, why the patch helped is indeed a miracle. Maybe it
changed the timing or causes a different serialization due to a mutex.
However, it did NOT solve the underlying problem.
Activated by Tom's question, i spent some more time on the problem
and managed to reproduce the problem reliably. The problem
actually happend when the number of available connection threads
is configured very low, as well as the the number of requests
per connection thread (e.g. 5 and 3). When the server accepts a
high number of requests, these are queued even without
guaranteeing resources to process these. The situation
is especially bad with bursty requests. When a connection thread
exits e.g. after 3 requests, and there are still many requests queued,
there is no mechanism to automatically trigger new
connection threads in this situation. When a client connects
in this situation to the server, some old (maybe obsolete) requests
are taken from the queue, but after this, the server might sit idle
even with a high number of requests queued.
I have commited a patch to cvs head, that processes these pending
requests, even when maxconns is exceeded. Maybe it is better to
restart exiting connection threads automatically or to limit the
number of queued requests at first hand; or maybe there is a callback
solution. However. I have removed the old - useless - patch
from the head version in CVS.
best regards
-gustaf neumann
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.