timers

Alan DeKok aland at deployingradius.com
Fri Apr 11 03:07:00 CEST 2014


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.


More information about the Freeradius-Users mailing list