Hi Alan, there are 2 options how DB can fail. 1) application fail, in this case host os will reply with icmp port unreachable, which should help with faster detection that DB failed 2) Host(where DB running ) failed, of network problem between radius and DB, in this case we will not receive any reply . And I am reproducing this scenario, by blocking incoming tcp packets from port 1521 (oracle) . On Mon, Jul 17, 2023 at 5:53 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jul 16, 2023, at 10:22 PM, Anatoliy <cphlpd@gmail.com> wrote:
Hi Alan , thank you for fast response, Unfortunately , I am really bad in programming , and freeradius will be better without my patches ... Now I am trying to better understand FR logic, When blocking tcp
connection
with DB , I just want to test scenario when DB down (for MW of due to some issue)
The solution here is to make sure that your database stays up. Plus, "TCP connection blocked" is NOT the same as "database is down".
When the database is down, existing TCP connections are closed, and new connections are refused. FreeRADIUS handles this situation well.
When the TCP connections are blocked as in your example, there are very few ways to recover from it. As I said, many SQL client libraries are not asynchronous. Which means that FreeRADIUS calls the library, and the library tries to connect to the SQL server. If the SQL server (or TCP connection) blocks, then so does the library, and so does FreeRADIUS.
There is pretty much nothing that we can do to fix that. We are *not* going to write our own non-blocking SQL client library. It's hard enough to write a RADIUS server.
So sql query always block core thread, and only option is to find way for faster detect that tcp session to DB fails ?
Read my previous message again. I answered this. My answer won't change if you keep asking the question.
For example max_retries option introduced in 3.2.3. But I think that retry_delay option should prevent all threads from connecting to DB for some time, if previous connection is fails.
I think I want a pony for my birthday. That's a nice thought. But it's not realistic.
And these messages tells about this , or my understanding is wrong ? Increasing retry_delay should help faster reply to NAS with Access-Accept.
No.
The server configuration is well documented. The "retry_delay" options is well documented. And it's *not* documented as "causing a faster reply to the NAS".
I really don't know how to make the documentation any more clear. I'm not sure why you're reading it, and concluding that "retry_delay" does something completely different from what the documentation says.
Stop wasting your time trying to say how FreeRADIUS "should" work. There are a lot of complex issues involved. You need to understand all of those issues before having an informed opinion on what "should" happen. It's also difficult to have an informed opinion if the existing documentation is misinterpreted.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html