[RADIATOR] radiator Timeout handling

[Michael]

Hi,

I'm having a couple issues with <AuthBy SQL>. Maybe it would be 
considered a bug i'm not sure.


1. the Timeout handling.
------------------------
 From my testing, it appears that radiator times out at this value, but 
seems to retry the sql query a second time, creating in another timeout 
count.

eg debug:
Tue Sep 14 12:48:21 2010: DEBUG: Handling accounting with Radius::AuthSQL
Tue Sep 14 12:48:21 2010: DEBUG: do query is: 'insert into `acct` <snip>
Tue Sep 14 12:48:25 2010: ERR: do failed for 'insert into `acct` <snip> 
SQL Timeout
Tue Sep 14 12:48:29 2010: ERR: do failed for 'insert into `acct` <snip> 
SQL Timeout
Tue Sep 14 12:48:29 2010: DEBUG: AuthBy SQL result: IGNORE, Database 
failure

Timeout is set for 4 seconds...
so, query executed at 12:48:21, ERR timed out 4 seconds later, appeared 
to re-try but didn't say anything, and another ERR timeout 4 seconds 
after that.  That's 8 seconds of course.  It doubles the Timeout value.

This is no good, for me.  If I set my SQL timeout value for 4 seconds, 
and my NAS timeout for 5 seconds, I expect my radiator to timeout before 
my NAS re-transmits.  my NAS will retry after 5 seconds because radiator 
hasn't responded.  And, radiator hasn't obeyed the timeout so it's still 
waiting for 8 seconds.  This causes the same accounting packet to enter 
radiator again, and causing another 8 seconds delay, and of course 
duplicate entries in the accounting logging since I'm also using 
AcctFailedLogFileName so the packet will eventually end up in the SQL 
table.


2. SQL Timeout issue #2.
------------------------
using the same debug example above, when the SQL query times out, it 
doesn't seem to use the FailureBackoffTime value. It only seems to use 
FailureBackoffTime when there is a connection failure, not a timeout.  
So, every query is still presented to the SQL server.  If the timeout is 
due to lets say a write lock, when the lock releases, all the queued 
insert statements are executed creating in sometimes up to 10 duplicate 
accounting entries.


3. AuthBy result after failure
------------------------------
an IGNORE occurs when the SQL query fails, but if AcctFailedLogFileName 
is used, and successfully wrote the accounting packet to the file, 
should radiator not then reply with an ACCEPT?  Dumping the accounting 
packet to a file, but replying with IGNORE will cause the NAS to go to 
the next radius server possibly accepting the entry, therefore the 
packet in the acct failed logfile, is a double.  Even if there's only 1 
radiator server in play, there will be an accounting packet entry in the 
failed log for each time the NAS retries.


Thanks in advanced for any advice,
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20100916/47f09f7a/attachment.html