Bug 1911

Summary: Configurable lock timeout
Product: Spamassassin Reporter: Klaus Johannes Rusch <KlausRusch>
Component: LibrariesAssignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: enhancement    
Priority: P5    
Version: SVN Trunk (Latest Devel Version)   
Target Milestone: Future   
Hardware: All   
OS: All   
Whiteboard: needs code

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)