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