timers

[Alan DeKok]

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.