Status-Server requests are blocked if an Access-Request is waiting for downstream service to respond

[Ignacio Arces]

> Let me guess.  You're running in debug mode?  i.e. with only one thread?

Thanks so much Alan. That was indeed the issue in our test environment.
When this issue happened in our prod env it was bc all threads were
blocked; we don't run FreeRADIUS in prod in debug mode.

On Thu, Nov 12, 2020 at 12:57 PM Alan DeKok <aland at deployingradius.com>
wrote:

> On Nov 12, 2020, at 1:26 PM, Ignacio Arces <ignacio.arces at gmail.com>
> wrote:
> >> If *one* Access-Request packet is blocked, then other threads can still
> > process Status-Server.  So no, you don't see a "single stuck auth request
> > impacting Status-Server".
> >
> > We confirmed this scenario in our test env. We forced the request handler
> > in our auth API to sleep for 60 seconds and then perform a simple
> > Access-Request with radtest. As expected, this single Access-Request were
> > blocked for 60s (we removed the curl timeouts and the container health
> > check for this test) and during this time all Status-Server request we
> sent
> > got blocked and returned only after the Access-Requests completed.
>
>   Let me guess.  You're running in debug mode?  i.e. with only one thread?
>
>   If you have *multiple* threads, then one stuck Access-Request will not
> block Status-Server packets.
>
>   Which is why I mentioned thread*S* above.  Not "one thread".
>
> > Agree. Our current focus is to improve our auth API. Nonetheless, I don't
> > think we are trying to hack up RADIUS, we just want to understand why
> it's
> > not working the way it's supposed to work. Maybe, we have
> > misconfigured something that's causing this behavior.
>
>   Yes.  You're only using one thread.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html