Alan DeKok-2 wrote
Because you only have one server. Split the server into two processes. One listens on network sockets and writes to the detail file. It shouldn't do anything else. Another reads from the detail file and writes to SQL.
I think this might just work will try it out today and see what's what. Alan DeKok-2 wrote
The problem isn't the detail file. The problem is that the server LOCKS, because all of the threads are locked, because the DB is locked. So it can't write to the detail file.
Splitting the server into two processes fixes that. It allows one process to write to the detail file, even if the reader is down, or is locked for many seconds.
I didn't say the detail file was at fault. I know the database is the culprit, but I just wanted a way to have packets written to the detail file regardless of the database then written to db at its own pace. Two processes seems like the best idea so far, I don't even know how I missed it. Cheers, amne -- View this message in context: http://freeradius.1045715.n5.nabble.com/Accounting-Response-dependence-tp503... Sent from the FreeRadius - User mailing list archive at Nabble.com.