Weird issue - threads bottleneck in post-proxy section

["RESTOUX, Loïc"]

Hi Alan,

Le 02/03/2015 17:14, Alan DeKok wrote :
> What happens when you use the “ok” module instead of your custom one?
> It might be down to bad interactions with the scheduler.

Do you mean the "always" module ? No problem at all with it, the rate is 
very good with an invocation in post-proxy section.

To be honest, we used custom-made modules for years without any problem, 
but they all execute very quickly (around 2 or 3 ms). The issue seems to 
appear if there are blocking (or time-consuming ?) operations in 
post-proxy and I'm not sure it is related to modules. So far, we 
encountered the issue with:
- rlm_rest requesting a high loaded REST server.
- rlm_exec invoking the /bin/sleep command (however in this case the 
rate is as bad in pre-proxy as in post-proxy so we can't rely on the 
result).
- rlm_lrs which calls usleep().

During this tests, we do not see high CPU or memory consumption. This is 
like FreeRadius have nothing to do.

If it's a scheduler problem, should we not see that all threads are 
active, but blocked somewhere ?

Regards,
-- 
/LRS/
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.