In the end we implemented our solution as a new C module rather than perl called by "rlm_perl". Thanks.
Our new module was designed to replace "rlm_sql" and meet these goals: - Be roughly equivalent to "rlm_files" in terms of speed - Utilise all the features of "rlm_files" - avoid re-inventing that wheel - Allow high rate of user-by-user updates; i.e. avoid config re-write as per "rlm_fastfile" - Simple for stability: no shared in-memory state (avoid locking and races) - Simple for stability: avoid complex on-disk structures like databases with dubious libraries - Simple for stability: easy mechanism to re-write entire config (say daily) to iron our errors - Simple for stability: re-use as much of freeRADIUS as possible; avoid writing lots of new code We acheived all these goals and can now process bring all our customers back onto our service in about five minutes. The price is a lot of i-nodes - we end up with one file per user in a dir tree. With "rlm_sql" it would take an hour or two only then with careful (and human driven) rate management. The main issues driving this delay were: - "rlm_sql" calls during EAP negotation instead of just at the end of EAP - Performance issues on our MySQL backend that we didn't have budget to resolve - Thread lock-up's inside MySQL library yet no MySQL server queries were active If this module is of interest to the community we are happy to contribute it. Cheers, Claude. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Cannot-control-attribute-ordering-via-rlm-perl-tp4875309p5147457.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html