Bug 3251 - sa-learn doesn't keep the lock file "fresh"
Summary: sa-learn doesn't keep the lock file "fresh"
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Learner (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P2 critical
Target Milestone: 3.0.0
Assignee: Theo Van Dinter
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 3208
  Show dependency tree
 
Reported: 2004-04-07 19:51 UTC by Theo Van Dinter
Modified: 2004-04-08 01:22 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Theo Van Dinter 2004-04-07 19:51:08 UTC 
from a mail I posted to sa-users:

fyi: I looked through the 2.63 code, and it looks like I'm recalling
2.5x learning (lock/unlock per message).  In 2.6x we seem to have fixed
that issue.  It does seem like we open the lock, then do sa-learn without
updating the mtime on the lock.  Another process, after 600 seconds 
(10 mins) can break the stale lock, which would cause problems. :(
I don't think that code's changed in 3.0, so I'll go open a bugzilla
ticket... <grrr>
Comment 1 Theo Van Dinter 2004-04-08 08:10:22 UTC 
I have a general fix in my head for this, just need to get it in code. ;)
Comment 2 Theo Van Dinter 2004-04-08 09:22:26 UTC 
ok, fix committed to head (r9940)

the short version is that we used to lock/unlock per message in 2.5x, and in 2.6x we lock on the first 
learn() call, keep calling tie_db_writable() per message (just returns since we're already locked), then 
calls untie() at the end.

so instead of just returning in tie_db_writable(), we will first "refresh" the lock via utime() before 
returning.  this will cause more I/O due to the inode updates, but it'll be a lot less than the 2.5x lock 
per message version.  we could kluge it for less I/O by keeping track of when the lock was put in place, 
then calculating how long it's been since that time, and only refreshing periodically between 0 and 
LOCK_MAX_AGE seconds.  that would require some collusion between BayesStore and Locker though, 
so I'm not going to worry about this unless I/O becomes an issue.  (I think the atime updates I/O << 
normal Bayes DB I/O ...)