radsqlrelay: can't it just give up sometimes?

[Phil Mayers]

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.