https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6942
--- Comment #19 from Mark Martinec <[email protected]> --- > > - the multi_tok_count_change (called by learn) does not atomically > > increment token's spam and ham counts. If multiple auto-learning > > child processes were to learn same tokens, we could lose some increments. > If we can use 2.6 lua scripting to replace pack/unpack, it's the only > sensible solution? Otherwise, nothing to worry. It's like winning in lottery. Here's another possibility for atomic adds: APPEND key value If key already exists and is a string, this command appends the value at the end of the string. If key does not exist it is created and set as an empty string, so APPEND will be similar to SET in this special case. Return value Integer reply: the length of the string after the append operation. Currently the value of a token key contains a single pair of ham/spam count. If we change that and let its value contain a concatenated string of ham/spam count pairs (their sum representing the actual counts), then learning a token would consist of a single atomic APPEND, no need for a prior MGET. If the result of APPEND append would indicate the string has already grown substantially, a transactional summation / shrinking of the string could then be performed (on a rare occasion) shortly after APPEND. The only problem that I see with above is that currently the pair is represented either as two bytes (2 chars) or as two 32-bit numbers represented in their binary form. This would need to be changed. -- You are receiving this mail because: You are the assignee for the bug.
