Connection pool reuse v3.0.x

Arran Cudbard-Bell a.cudbardb at
Sat Jul 12 19:55:22 CEST 2014

A few people have requested this be added since v3.0.0 was released.

Occasionally for some complex modules like rlm_ldap, it's useful to
run different sets of queries against the same server.

People usually achieved this by using multiple instances of the same
module (though I've also seen some quite creative uses of xlat).

When multiple instances of the same module were used, a new set of
connections were opened for the module.

Where many instances of the same module were used the number of open
connections could get very large.

The connection pool reuse feature allows multiple instances of the 
same module to share a single connection pool.


ldap baz {
	pool = ldap

ldap {
	pool {
		<pool parameters>

ldap foo {
	pool = ldap

ldap bar {
	pool = foo

The server will automatically fix the loading order of modules, so in this
case even though baz is listed first, ldap will get instantiated first.

The server will also detect cycles, i.e.

ldap foo {
	pool = bar

ldap bar {
	pool = foo

and error out.

If you specify server settings in module instances which use another module's
connection pool they will be ignored.

Log messages involving the shared connection pool will have prefixes 
consistent with the module that 'owns' the connection pool, not the modules 
that use it.

You cannot use connection pools from modules of a different type, doing so
will produce an error.

I've worked through the obvious test cases for this feature, but if anyone 
else wants to try it out, that would be much appreciated.


Arran Cudbard-Bell <a.cudbardb at>
FreeRADIUS Core Developer

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <>

More information about the Freeradius-Users mailing list