It's a faulty design that leaves more than half a server's CPU capacity
unused due to the mere fact that they wait for all threads to complete
before moving in a new batch.
I can't speak to what you see on your server, but that is not how it is
running on my server. I just double checked again to make sure I am not
crazy, but as I watch the thread count on my server (decludeproc) the
threads fluctuate between 7 - 30 ( threads currently set to 50). It is not
uncommon to see the threads move as follow: 11,8,10,7,15,.... While I was
watching it I never seen a case where it went down low enough for the
WAITFORMAIL setting to kick in. Watching the proc/work directory you can
see files moving in and out, but never really emptying out. Its possible
what I am seeing is an anomaly or maybe I am interpreting it wrong.
Maybe David can comment on this.
Darrell
------------------------------------------------------------------------
invURIBL - Intelligent URI filtering plug-in for Declude, mxGuard, and ORF.
Stop spam at the source the spamvertised domain. More effective than
traditional RBL's. Try it today - http://www.invariantsystems.com
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
