|Summary:||Configurable lock timeout|
|Product:||Spamassassin||Reporter:||Klaus Johannes Rusch <KlausRusch>|
|Component:||Libraries||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Version:||SVN Trunk (Latest Devel Version)|
Description Klaus Johannes Rusch 2003-05-13 17:54:23 UTC
The lock timeout for DBWhitelist is 30 seconds (not configurable), the lock timeout for Bayes is 10 or 300 seconds. Please add a configuration option to reduce lock timeouts and max lock age (since --add-to-whitelist etc makes little sense in read only mode, a different lock timeout for explicitly modifying the whitelist/blacklist would be good, too)
Comment 1 Duncan Findlay 2003-06-06 23:55:31 UTC
enhancement -> 2.70
Comment 2 Duncan Findlay 2004-11-30 20:37:55 UTC
This seems trivial. Add a new option awl_timeout nnn 30 seconds seems to be hardcoded into DBBasedAddrList.pm:75
Comment 3 Daniel Quinlan 2004-11-30 20:45:40 UTC
Subject: Re: Configurable lock timeout > awl_timeout nnn We should just have one configurable timeout for the locking code.
Comment 4 Justin Mason 2004-12-01 11:24:00 UTC
'We should just have one configurable timeout for the locking code.' disagree. How long to use for a timeout depends entirely on the calling code's design, not on the abstracted locking subsystem used. for example: - opportunistically attempting to autolearn during scanning: short lock timeout - AWL update: short lock timeout - user-initiated manual training: long timeout we've been through this before IIRC, with a lock-timeout specified in the locking code, and ran into many problems that resulted in us changing to the timeout being controllable from the high-level calling code instead.
Comment 5 Daniel Quinlan 2005-03-30 01:08:52 UTC
move bug to Future milestone (previously set to Future -- I hope)