Juan Pablo L. wrote:
during tests i have noticed that when these connections (or some of the connections) are not used for a long period of time (some hours) because of low traffic (e.g between 2 - 4 am) the connections becomes idle and even though they are not disconnected it gives an I/O error when you try to send anything to the database (even though the underlying socket is created with the keepalive flag).
That's a problem. But my larger question is why are you connecting to SQL in your module? rlm_sql already has code to handle queries, and is DB independent. See rlm_sqlippool for how to use SQL from another module. Or, if you still want to use your own connections, use version 3, and see src/main/connection.c. It's a connection pool for exactly this kind of reason. It's used by the ldap, redis, and sql modules. It has min/max counters, idle timeouts, etc. It should solve the problems you're seeing.
Having said that, i have added timers to these connections that monitor the time of inactivity that they have and once the threshold is reached the module disconnects them, so when a next time a connection is requested the pool just check if connected or not, if not connected if connects it and gives it to the caller, very simple really.
That's duplicate effort. The server already has all of that code.
The problem is, that all the nice timers work in an epoll in a thread inside the module. After researching the lists i have found out that that is not possible to do (to run a thread inside a module) ... so i would like to ask if there is any functionality in freeradius i m not aware of that could help me with this issue ? or if any of you faced the same situation, how you fixed that ? ... even though i have read that according to the freeradius developer that is a bad design, i really do not know of any other way how to deal with this situation, so i would really appreciate any feedback on this.
There's no need to run additional threads. We were against that historically because nearly all intended uses of child threads were pointless.
P.S: i do not want to start an argument whether is or it isnt a bad/good design, i think that was established already in the past, but as i said, i do not know how to deal with the idle connections problem in an efficient manner (i dont want to open/close connections every time i get a radius package but i also do not want to keep connections open using database/network/server resources when they are not needed).
The connection pool API in v3 does all of this for you. It's really quite simple to use. Alan DeKok.