1.1.7 rlm_detail locking is broken

[Brian De Wolf]

On 11/29/07 17:46, Brian De Wolf wrote:
> Expect a patch, soon enough...

Here's the patch, as promised.  Now, instead of radrelay's previous behavior, 
radrelay will attempt to open and lock <detail>.work.  If it can, it will then 
read/transmit all of the entries and delete <detail>.work.  If it can't lock, it 
will simply try locking later.  If it doesn't exist, it will check if <detail> 
has entries and if so it will move <detail> to <detail>.work (and make a new 
<detail>).

It seems to move faster, but that's because I removed some of the sleeps to make 
sure writing had completed since that should be handled by the locks now. 
Luckily, my relay destinations aren't production yet, so I can keep testing with 
a decent load.

How does it look?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: radrelay.diff
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20071203/e199c822/attachment.ksh>