Bug 1911 - Configurable lock timeout
Summary: Configurable lock timeout
Status: RESOLVED WORKSFORME
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: 2022-03-06 16:15 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

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)
Comment 6 Henrik Krohns 2022-03-06 16:15:53 UTC 
Closing ancient stale bug.