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. Example: 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 Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2