On 11/29/2012 05:14 PM, laurent.feron@free.fr wrote:
Hello,
In a perl script (where authorize() and authenticate() are defined), i was able to set a global variable. when a radius request comes, the script may modify the variable, and the next request has the new value. I test with radiusd -X, and everything is fine.
when radiusd is started as a daemon, 5 threads (default value) are started. And now, i understood i have 5 different perl "environments". Meaning, when i start the first radtest that modifies the global variable, only the sixth request can view the global variable modified by the first request( i guess the sixth one turns into the first thread).
I hope my explanation is clear. I would like to know if it possible to have a unique sharing enviroment (the basic solution is maybe to have only one thread, but it should be good for performance)
Just for your information, i would like to "cache" some information... the script has to find which OTP server the user is defined on. The second time the search is not necessary... i use Tie::Hash::Expire module for caching information.
Is there a problem with having each thread perform it's own caching? It will take slightly longer to populate the cache than if it was shared but is that an issue in practice? You could borrow a technique from web servers where requests are typically processed in independent processes but shared caching between the processes is desired by utilizing memcache. memcached is a stand alone process (daemon) that holds a hash table in memory and processes connect to it via sockets (either inet or unix). There are several memcache client language bindings, pretty sure there is one for Perl. Google memcache, you'll find a ton of information about it. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/