http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5388
------- Additional Comments From [EMAIL PROTECTED] 2007-04-13 03:59 -------
(In reply to comment #7 on bug 5416, which I'd prefer to keep here to keep the
thread in one place ;)
> FWIW/HTH: it's my theory that this is more likely to happen on slower
> machines,
> or spamd installations with lots of large custom rulesets (are custom rulesets
> loaded during the tests?), b/c from what I understand, the first spamc
> connection attempt from those test scripts *might* be accepted by the server
> in
> the very short period of time between the instant the last child forks and the
> instant the first forked child finishes reporting that it's idle (ready to
accept).
>
> So what my patch was trying to do was give SpamdForkScaling.pm a way to know
> if
> it was still in "startup" phase, which would have overriden the trigger for
> "overloaded" mode. But I botched the implementation as you can tell from
> Justin's commentary...
yeah -- you see, what I would expect to happen in that situation is that the
parent spamd would just fork *more* children. if the load then wasn't there to
keep that many kids active, they'd exit, and it'd settle down to a steady state
quickly enough.
You can fake the problem situation described above, by adding this JMD line to
update_child_status_idle() in SpamdForkScaling.pm:
sub update_child_status_idle {
my ($self) = @_;
warn "JMD faking slow machine with a sleep"; sleep 10;
# "I b1 b2 b3 b4 \n "
$self->report_backchannel_socket("I".pack("N",$self->{pid})."\n");
}
even with this, the spamd continues to work ok.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
