You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Ty! Boyack <ty...@nrel.colostate.edu> on 2008/10/08 18:11:27 UTC
Re: [LIST:spamassassin-dev] spamc failover behavior
I submitted a patch to address this behavior -- you can see the
discussion at
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5871. I think
the goal is to include this in 3.3, but you can grab the patch from here
if it helps:
https://issues.apache.org/SpamAssassin/attachment.cgi?id=4303&action=view
What I found was that the behavior your describe below is correct. The
patch adds an option of --filter-retries to specify how many times it
should retry the filtering process (moving to the next spamd host for
each retry) before giving up.
Hope this helps.
-Ty!
Iavor Stoev wrote:
> Hello,
> First my system information is:
> OS - Debian Etch
> SA version - 3.2.3
>
> I am trying to use SpamAssassin in the following setup to accomplish
> load balancing:
>
> I have 3 testing servers with spamd installed and configured to accept
> network connections from a whole /24 network.
> On an another testing machine I invoke spamc with the following options:
>
> cat test-email.txt | spamc -c -t 120 -p 783 -H -d
> server1.com,server2.com,server3.com
>
> In that scenario everything is ok and works as expected.
> The spamc client connects to a random server from the round robin pool
> and receives an answer with the spam score for the email from every
> server.
>
> Ok then I tried to make some trouble.
>
> On server1.com I stopped the Spamd so there was no service listening
> on port 783.
> On server2.com I added a firewall rule using iptables to DROP requests
> to port 783.
> On server3.com I left the Spamd working without any intervention.
>
> I executed again the spamc command written above several times and
> everything was perfect.
> Depending on which server is accessed first from the spamc, sooner or
> later I always received an answer from server3.com (the only server
> that is operational).
>
>
> I reverted all the servers back to fully operational mode and decided
> to check what will happen if one of the servers is heavily loaded and
> don't respond to the spamc request in the timeout limit.
>
> On server3.com I executed:
>
> killall -STOP spamd
>
> and the effect was that the server was with port 783 open and you can
> establish a successful TCP connection but the server doesn't return
> anything to the spamc client.
>
>
> So when I invoked the spamc again and it accessed server3.com the
> spamc waited for response from the server and when it didn't received
> one for 120 seconds it returned spam score 0/0, instead of connecting
> to another server from the pool.
>
> Could you tell me is that behavior indented and if not what can I do
> to make the spamc to connect to another server in this scenario?
>
>
> Thank You
>
> Iavor Stoev
>
--
-===========================-
Ty! Boyack
NREL Unix Network Manager
ty@nrel.colostate.edu
(970) 491-1186
-===========================-
Re: [LIST:spamassassin-dev] spamc failover behavior
Posted by Iavor Stoev <ia...@icdsoft.com>.
Hello Ty! Boyack,
It works like charm with the patch that you provided.
I just want to report that you have to invoke spamc with
--filter-retries with some value (greater than 1 in my setup case) to
achieve the desired failover behavior, even that in the spamc help is
described that it has default value 3.
I don't know if that is a code or documentation bug.
--filter-retries retries
Retry filtering this many times if the spamd
process fails (usually times out) [default: 3]
Thank You again !
Iavor Stoev
Ty! Boyack wrote:
> I submitted a patch to address this behavior -- you can see the
> discussion at
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5871. I think
> the goal is to include this in 3.3, but you can grab the patch from
> here if it helps:
> https://issues.apache.org/SpamAssassin/attachment.cgi?id=4303&action=view
>
> What I found was that the behavior your describe below is correct.
> The patch adds an option of --filter-retries to specify how many times
> it should retry the filtering process (moving to the next spamd host
> for each retry) before giving up.
>
> Hope this helps.
>
> -Ty!
>
>
>
> Iavor Stoev wrote:
>> Hello,
>> First my system information is:
>> OS - Debian Etch
>> SA version - 3.2.3
>>
>> I am trying to use SpamAssassin in the following setup to accomplish
>> load balancing:
>>
>> I have 3 testing servers with spamd installed and configured to
>> accept network connections from a whole /24 network.
>> On an another testing machine I invoke spamc with the following options:
>>
>> cat test-email.txt | spamc -c -t 120 -p 783 -H -d
>> server1.com,server2.com,server3.com
>>
>> In that scenario everything is ok and works as expected.
>> The spamc client connects to a random server from the round robin
>> pool and receives an answer with the spam score for the email from
>> every server.
>>
>> Ok then I tried to make some trouble.
>>
>> On server1.com I stopped the Spamd so there was no service listening
>> on port 783.
>> On server2.com I added a firewall rule using iptables to DROP
>> requests to port 783.
>> On server3.com I left the Spamd working without any intervention.
>>
>> I executed again the spamc command written above several times and
>> everything was perfect.
>> Depending on which server is accessed first from the spamc, sooner or
>> later I always received an answer from server3.com (the only server
>> that is operational).
>>
>>
>> I reverted all the servers back to fully operational mode and decided
>> to check what will happen if one of the servers is heavily loaded and
>> don't respond to the spamc request in the timeout limit.
>>
>> On server3.com I executed:
>>
>> killall -STOP spamd
>>
>> and the effect was that the server was with port 783 open and you can
>> establish a successful TCP connection but the server doesn't return
>> anything to the spamc client.
>>
>>
>> So when I invoked the spamc again and it accessed server3.com the
>> spamc waited for response from the server and when it didn't received
>> one for 120 seconds it returned spam score 0/0, instead of connecting
>> to another server from the pool.
>>
>> Could you tell me is that behavior indented and if not what can I do
>> to make the spamc to connect to another server in this scenario?
>>
>>
>> Thank You
>>
>> Iavor Stoev
>>
>
>