Hi All, Alan mercilessly ripped out all the connection pool logic in rlm_sql and replaced it with calls to the generic connection pool API which is new in 3.0. In anyone's running an SQL DB and wants to test it'd be much appreciated. New code is in Master@HEAD. WARNING: This change breaks compatibility with V2.0 configs, you will need an empty pool { } stanza in each instance of rlm_sql configuration or the server will fail to load. See here https://github.com/alandekok/freeradius-server/blob/master/raddb/modules/sql for the full pool configuration sub-section. The following configuration items no longer have any effect: num_sql_socks, connect_failure_retry_delay, lifetime, max_queries. Their equivalents are, (start, mix, max, spare), *none* , lifetime, uses. DEVELOPERS NOTE: From this point onwards any new modules which use a pool of connections, or would benefit from a pool of connections but doesn't use the connection API, will not be accepted. Code for connection pool is here: https://github.com/alandekok/freeradius-server/blob/master/src/main/connecti... #include <freeradius-devel/connection.h> -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Hi,
WARNING: This change breaks compatibility with V2.0 configs, you will need an empty pool { } stanza in each instance of rlm_sql configuration or the server will fail to load. See here https://github.com/alandekok/freeradius-server/blob/master/raddb/modules/sql for the full pool configuration sub-section.
The following configuration items no longer have any effect: num_sql_socks, connect_failure_retry_delay, lifetime, max_queries. Their equivalents are, (start, mix, max, spare), *none* , lifetime, uses.
DEVELOPERS NOTE: From this point onwards any new modules which use a pool of connections, or would benefit from a pool of connections but doesn't use the connection API, will not be accepted.
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well? one of my customers has very high numbers of LDAP calls in authorize, and needs to do LDAPS. The TLS session setup load is very uncomfortable right now. Greetings, Stefan Winter
Code for connection pool is here: https://github.com/alandekok/freeradius-server/blob/master/src/main/connecti...
#include <freeradius-devel/connection.h>
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org <mailto:a.cudbardb@freeradius.org>
Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
DEVELOPERS NOTE: From this point onwards any new modules which use a pool of connections, or would benefit from a pool of connections but doesn't use the connection API, will not be accepted.
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well? one of my customers has very high numbers of LDAP calls in authorize, and needs to do LDAPS. The TLS session setup load is very uncomfortable right now.
Alan said he was going to tackle maybe today or tomorrow. If it's not done in a week or so i'll have a go at it. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Hi,
DEVELOPERS NOTE: From this point onwards any new modules which use a pool of connections, or would benefit from a pool of connections but doesn't use the connection API, will not be accepted.
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well? one of my customers has very high numbers of LDAP calls in authorize, and needs to do LDAPS. The TLS session setup load is very uncomfortable right now.
Alan said he was going to tackle maybe today or tomorrow. If it's not done in a week or so i'll have a go at it.
Great news! With a bit of luck, I might recruit him as volunteer for testing that :-) Stefan
Hi,
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well? one of my customers has very high numbers of LDAP calls in authorize, and needs to do LDAPS. The TLS session setup load is very uncomfortable right now.
why do they have a very high number of calls to LDAP? Are they calling LDAP in the outerID of EAP requests? are they calling LDAP for non local requests? they really should wrap the outerID LDAP query inside some unlang to protect it from queries that shouldnt hit it.. alan
Hi,
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well? one of my customers has very high numbers of LDAP calls in authorize, and needs to do LDAPS. The TLS session setup load is very uncomfortable right now. why do they have a very high number of calls to LDAP? Are they calling LDAP in the outerID of EAP requests? are they calling LDAP for non local requests? they really should wrap the outerID LDAP query inside some unlang to protect it from queries that shouldnt hit it..
No, first thing I checked :-) Only happens on inner, it's a bit a peculiar design. Stefan
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 10/17/2011 06:58 PM, Alan Buxey wrote:
Hi,
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well? one of my customers has very high numbers of LDAP calls in authorize, and needs to do LDAPS. The TLS session setup load is very uncomfortable right now.
why do they have a very high number of calls to LDAP? Are they calling LDAP in the outerID of EAP requests? are they calling LDAP for non local requests?
N.B. as per the discussion on the Janet-roaming mailing list a while back, and on this list a bit later - if you're running PEAP/MS-CHAP, even running LDAP on the inner tunnel will, currently, incur 3 LDAP lookups, one for each pass through the inner tunnel - EAP-identity, EAP-MSCHAP, EAP-success. Once I've failed my exam tomorrow (haha! just kidding... I hope) I will have some free time, and will revisit the EAP code changes needed to make this not happen. Or you could use the vilest unlang ever devised[1] # stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message =~ /^0x02..00061a..$/)) { noop } else { # rest if your inner EAP goes here } BWahahahaha! Cheers, Phil [1] Unlang may not actually be the vilest ever devised
Hi,
Or you could use the vilest unlang ever devised[1]
# stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message =~ /^0x02..00061a..$/)) { noop } else { # rest if your inner EAP goes here }
BWahahahaha!
yep, thats the sort of thing to protect the LDAP hit - after all, why do the query for things that are of no benefit? I guess the same is true for other queries to other authorize modules? alan
Hi,
Or you could use the vilest unlang ever devised[1]
# stop processing authorize on eap identity or mschap success/fail if ((EAP-Type == 1) || (EAP-Message =~ /^0x02..00061a..$/)) { noop } else { # rest if your inner EAP goes here }
BWahahahaha!
Now THAT looks useful! That message of yours deserves being flagged "Important" :-) Will go about trying that when I'm back from that meeting in Vienna. See some of you there anyway :-) Greetings, Stefan
Cheers, Phil
[1] Unlang may not actually be the vilest ever devised - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi,
Now THAT looks useful! That message of yours deserves being flagged "Important" :-) Will go about trying that when I'm back from that meeting in Vienna. See some of you there anyway :-)
its a nice extended version of a protection around the module. alternatively, dont use the ldap native module but do the LDAP stuff in a nice little bit of PERL using LDAP CPAN modules and then call PERL instead of LDAP module for authorise function - the PERL module would already have the connection to LDAP open so no bring-up/tear-down issues as its resident... alan
Stefan Winter wrote:
Sounds nice! Out of curiosity: any plans to make LDAP connections persistent and pooled as well?
? They are already... The new connection pool code is a way to have *consistent* pools across multiple modules. They all share a common configuration, and benefit from simple debugged code. It also means removing duplicate code in the current source, which is always a good idea. Alan DeKok.
On 10/17/2011 06:11 PM, Arran Cudbard-Bell wrote:
DEVELOPERS NOTE: From this point onwards any new modules which use a pool of connections, or would benefit from a pool of connections but doesn't use the connection API, will not be accepted.
Can we add / will you accept a patch for opening connections in the background / a thread? Could be a generic per-pool option. There's some code in that LDAP branch I created a while back. This is particularly important for rlm_ldap; lots and lots of .ac.uk people have problems with FR behaviour during LDAP outages. Even setting net_timeout really low, you incur net_timeout on each request before RLM_FAIL and configurable failover can kick in. (n.b. I don't personally use LDAP, but I'll port the LDAP code to use the connection pool if this will help...)
On 10/17/2011 07:31 PM, Phil Mayers wrote:
On 10/17/2011 06:11 PM, Arran Cudbard-Bell wrote:
DEVELOPERS NOTE: From this point onwards any new modules which use a pool of connections, or would benefit from a pool of connections but doesn't use the connection API, will not be accepted.
Can we add / will you accept a patch for opening connections in the background / a thread? Could be a generic per-pool option. There's some code in that LDAP branch I created a while back.
This is particularly important for rlm_ldap; lots and lots of .ac.uk people have problems with FR behaviour during LDAP outages. Even setting net_timeout really low, you incur net_timeout on each request before RLM_FAIL and configurable failover can kick in.
...or some other async way I should add - I know some people were keen on using the "Ldap connect from FD" and managing the TCP connection ourselves. I think I even wrote that code too...
Phil Mayers wrote:
Can we add / will you accept a patch for opening connections in the background / a thread? Could be a generic per-pool option. There's some code in that LDAP branch I created a while back.
I'm wary of that.
This is particularly important for rlm_ldap; lots and lots of .ac.uk people have problems with FR behaviour during LDAP outages. Even setting net_timeout really low, you incur net_timeout on each request before RLM_FAIL and configurable failover can kick in.
A better approach (IMHO) is to have configurable delays for outages. i.e. "if all connections are down, try to reconnect only once a second". This gets the same result of returning "no connection" to the module, but is much faster. And because that could would be in the connection API, all of the modules would benefit (SQL, LDAP, etc.) The only real question is which algorithm to use. The simplest I can think of is to track failed connection attempts. Once the code has a failed connection attempt, it shouldn't try to open a new connection for 1 second. Once a connection succeeds, it can open more connections right away.
(n.b. I don't personally use LDAP, but I'll port the LDAP code to use the connection pool if this will help...)
It will. I've taken a look at the LDAP code, and it's pretty bad. I'd prefer to avoid it. Alan DeKok.
On 10/17/2011 06:11 PM, Arran Cudbard-Bell wrote:
Hi All,
Alan mercilessly ripped out all the connection pool logic in rlm_sql and replaced it with calls to the generic connection pool API which is new in 3.0.
In anyone's running an SQL DB and wants to test it'd be much appreciated.
SQL pool seems to work, but I'm still getting a segfault on fast session resumption - more info to follow in the original thread.
Phil Mayers wrote:
SQL pool seems to work,
Good. I've added some code to limit failed connection attempts. If a connection fails, it won't try opening a new connection until at least 1 second has passed. I've also reworked the mutex locks when opening a new connection. The new connection is now opened *without* the mutex lock being held. This means that existing (i.e. working) connections can be grabbed from the pool while it's opening a new connection. i.e. if there's suddenly an issue which prevents new connections from being opened, existing ones can still be used && released. The next thing is to limit the number of connections to one if there are no threads. It makes no sense to open a dozen connections when the server is running in debugging mode. Alan DeKok.
The next thing is to limit the number of connections to one if there are no threads. It makes no sense to open a dozen connections when the server is running in debugging mode.
Well, you know, except for debugging ? -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
Arran Cudbard-Bell wrote:
The next thing is to limit the number of connections to one if there are no threads. It makes no sense to open a dozen connections when the server is running in debugging mode.
Well, you know, except for debugging ?
$ radiusd -xxx ... Debugging, with threads. $ radiusd -X ... Debugging, without threads. Does it make sense to open 5 DB connections when there's only one thread? Alan DeKok.
On 17 Oct 2011, at 22:11, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
The next thing is to limit the number of connections to one if there are no threads. It makes no sense to open a dozen connections when the server is running in debugging mode.
Well, you know, except for debugging ?
$ radiusd -xxx ...
Debugging, with threads.
$ radiusd -X ...
Debugging, without threads.
Does it make sense to open 5 DB connections when there's only one thread?
I'm not sure I really see the harm in it. It's been drilled into people that to find problems they should run the server in debugging mode. If the issue they're having only occurs when multiple connections are used it'll be confusing. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers -
Stefan Winter