Michael Monnerie wrote:
> OK, learning is quick anyway, so no problem here. The expire will
> definitely run much longer, as you say. But what happens when SA wants
> to auto-learn another message while expire runs? Will it wait and
> timeout or just skip autolearning? Skipping would be no probl
On Donnerstag, 11. Mai 2006 22:22 Theo Van Dinter wrote:
> It depends what "timeout" means in this context. What's going on is
> that anytime a process needs to get a write lock on the db, there's
> contention if other processes already have it locked. By default,
> processes can wait either 300s
On Thu, May 11, 2006 at 10:10:39PM +0200, Michael Monnerie wrote:
> OK, learning is quick anyway, so no problem here. The expire will
> definitely run much longer, as you say. But what happens when SA wants
> to auto-learn another message while expire runs? Will it wait and
> timeout or just ski
On Donnerstag, 11. Mai 2006 20:06 Theo Van Dinter wrote:
> > On http://wiki.apache.org/spamassassin/BayesForceExpire is says you
> > should stop SA before --force-expire, is that a must or a
> > recommendation? The man page doesn't ask for it.
>
> It's completely unnecessary to stop SA (that'd be a
On Donnerstag, 11. Mai 2006 20:00 Matt Kettler wrote:
> First, adding --sync is redundant. --force-expire implies --sync
> because it would be foolish for SA to attempt expiry without syncing
> first.
I found that in the documentation after I sent the mail.
> Your expiry will take much longer. On
On Thu, May 11, 2006 at 06:17:14PM +0200, Michael Monnerie wrote:
> > > bayes: synced databases from journal in 11 seconds: 1968 unique
> > > entries (3059 total entries)
> > That's the journal sync, not the expiry part. The expiry part takes
> > much longer.
>
> It comes from "sa-learn --force-ex
Michael Monnerie wrote:
> On Donnerstag, 11. Mai 2006 08:06 Matt Kettler wrote:
>>> And tonights expiry for server #1:
>>> bayes: synced databases from journal in 11 seconds: 1968 unique
>>> entries (3059 total entries)
>> That's the journal sync, not the expiry part. The expiry part takes
>> much
Hello Michael,
Wednesday, May 10, 2006, 5:21:14 PM, you wrote:
> And why was SARE_FORGED_EBAY set down to 4? It was so nice at 100+...
Originally it was set to 104 to over-ride user driven whitelists, but
I felt that was somewhat out of standard practices to have a single
rule flag a message as
On Donnerstag, 11. Mai 2006 08:06 Matt Kettler wrote:
> > And tonights expiry for server #1:
> > bayes: synced databases from journal in 11 seconds: 1968 unique
> > entries (3059 total entries)
> That's the journal sync, not the expiry part. The expiry part takes
> much longer.
It comes from "sa-l
Michael Monnerie wrote:
> On Mittwoch, 10. Mai 2006 23:41 Matt Kettler wrote:
>
>> Particularly on servers with a site-wide DB used against broadly
>> diverse spread of mail, increasing the token limit will improve
>> accuracy.
>>
>> However, this comes at the expense of increased storage needs
On Mittwoch, 10. Mai 2006 23:41 Matt Kettler wrote:
> Particularly on servers with a site-wide DB used against broadly
> diverse spread of mail, increasing the token limit will improve
> accuracy.
>
> However, this comes at the expense of increased storage needs and
> slower performance. (In partic
Michael Monnerie wrote:
> Dear SA users, I've had an offlist comparison of bayes DBs, and we found
> some interesting differences. We're trying to find out why bayes on
> server #1 makes better scores.:
>
> Server #1 local.cf (SA 3.1.1):
> Server #1 bayes dump:
> 0.000 0 93053
12 matches
Mail list logo
