http://bugzilla.spamassassin.org/show_bug.cgi?id=3483
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[review] bayes _journal not |bayes _journal not syncing
|syncing to _toks |to _toks
------- Additional Comments From [EMAIL PROTECTED] 2004-07-14 22:42 -------
reverting out of review state for now.
ok, so the last patch is good, but it doesn't actually fix the problem. the
main problem is that the
opportunistic calls are made from scan(), but scan() isn't called _at all_ if
is_scan_available() fails.
I need to think about this some more, but I'm thinking that the autolearn code
ought to call the
opportunistic code as well, and it really ought to be both, here's the thoughts:
- scan() will cause journal updates with timestamps, but autolearning may be
disabled. so if the opp
calls are only made from autolearning, the journal can grow huge from the
timestamp updates and
never sync.
- autolearning can occur when scanning doesn't (this ticket), and autolearning
actually also adds tokens
which is what causes the need for an expire.
a possibility is to remove the call from scan() and put it in PMS::check()
instead, which can call it post
scan and autolearn. the problem is that autolearn, and check, don't require
the bayes db to be tied at
all, which the opportunistic calls do, as does scan, which is why it's there
now... hrm. what a bugger.
ok, new thought:
- move it from scan() to is_scan_available(). the function is called a lot, so
the opportunistic calls will
occur multiple times per message which isn't good but it's not terrible. if we
add in a flag to
opportunistic calls that specifies journal_only, that'll let it exit really
quick if there's nothing to be done.
thoughts?
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
