Roberto,

I get the following log entry periodically. It appears to happen when SF is re-reading it's config files (every minute) and a rejected email comes in at the same time.

If this is the case, then this may be an oversight on your part as the email in question is neither quarantined or delivered....just dissapears. I don't believe that this is the outcome that you intentially wanted, so it might be a bug. I have emailed you the logfile for you to check my results.

Database is busy - cannot quarantine EMail from xxx@xxxxx to xxx@xxxx

 

 

Roberto,

Sorry, it was a typo by me... the delete of expoired records is set to 30 (is this the default?? dunno).

However, re your comment "Queueing the archival requests proved to be a bad idea" ....err...NO.

just deleting the email is much more of a bad idea. How do you know that the email you descided to not quarantine (and subsiquently delete) was actually an email from your solicitor, your accountant, or your biggest customer?? Ther may have inadvertantly got onto a DBN list, mucked up their SPF record, who knows? This is exactly what the quarantine is for.

I would stream all quarantine destined emails to a folder whilst the DB clieaup is in progress, and when it's finished, insert them into the DB.

So, to recap, IMHOto just drop emails when you are doing a DB cleanup is a BIG mistake that needs immediate attantion, otherwise....whay use is the quarantine if you can't guarantee that you will put the emals in it?

 

 

We may re-address a different queing process to spool to disk emails if the database is busy, but that will be done after the next major upgrade of SpamFilter is released in a few weeks.

Thankyou..
This feature will be so much welcome.

StevenJohns,

"Unfortunately" I have to correct you on the "most". I'd be happy if it was that way, so we'd have to support only one DB platform, but in reality the only one that is hardly used is Oracle. MySQL, MS SQL and Access users are pretty evently spread out.

No problem for the innodb engine, we simply do not use it by default as some users, especially back in 2002-2003 with the earlier versions of SpamFilter, did not have it installed. However SpamFilter does support it, so DB admins are welcome to change from MyISAM.

As we have to support multiple platforms, changing SQL code for MySQL is something we'd rather not do. In this particular case, however, it's something we absolutely do not *want* to do. The insert delayed will cause an additional  thread to be spawned on MySQL for each queued request. We've seen tables being locked for several minutes at times, especially during backups and cleanup jobs on large databases. On busy mail servers, in a few minutes there could be several thousands of emails being quarantined. An insert delayed command would cause thousands of queued threads to be created on the MySQL database server, making it very likely to crash...
This is the very reason we changed SpamFilter's behavior, as previously SpamFilter was queueing the insert requests, waiting for the database to start responding. This was leading to SpamFilter to now be creating thousands of queued threads, ...eventually crashing the server!