Bug 1911 - Configurable lock timeout
Summary: Configurable lock timeout
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard: needs code
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-13 17:54 UTC by Klaus Johannes Rusch
Modified: 2005-03-29 16:08 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
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)