On 11/06/2013 07:32 AM, Stefan Winter wrote:
Can't radqlrelay be a bit more clever about this, like try three times, and if the query is consistently rejected, save it to a ".reject" file and move on?
I can't be the only one who falls into this, am I?
No, we've had similar problems, but not for a while now - I went through query-by-query, column-by-column and made damn sure all our queries would execute at all times. I think the issue with modifying radsqlrelay is that it's hard to know what a general, robust solution to this problem would look like. I guess the simplest solution would be to try a line for N times/M seconds, then give up and write it to a .failed logfile which the admin can monitor However, if you're using the newer radsqlrelay which sends the logs in batches and uses transactions, you have to: 1. Rollback the transaction 2. Seek backwards in the log to your start point 3. Re-process from there 4. Remember the logs that failed and ignore them ...so it gets more complex quite quickly. In the past, one solution I considered was writing "--" into the file at the start point of the failed query, which has the advantage of putting the "skip" state into the file and simplifying the implementation somewhat, but it has bad code smell ;o) As others have pointed out, decoupled accounting has some other ways to handle this; OTOH it can't handle post_auth and AFAIK doesn't batch insertions into transactions, so has some of the performance issues of the old radsqlrelay. In a way, what we really need is something like an ORM that maps radius accounting & post-auth packets to SQL in a more intelligent way than using string interpolation, and that could realise a mapping was going to fail before it tried the SQL query.