Hi,
The lack of the _clones options is not my (primary) problem but I
think it was a good functionality. I understand that simplifying,
refactoring and optimizing the code is important and that the changes
done are probably for the better but being unable to instantiate
several rlm_perl instances to take care of different circumstances
based on the NAS-IP or something else is a huge problem for me.
Otherwise, if we have a working radiusd thread pool and there's one
perl interpreter per radiusd thread/process it's OK. The requests
won't be waiting each other to be processed. But if there can be only
one perl interpreter shared between the whole thread pool, there will
be no performance benefits at all - just the opposite - resources
won't be used effectively and there will be requests which will wait
for minutes... I've experienced it.
Anyways my main trouble is being unable to use multiple rlm_perl
instances like this (I've put the comments to illustrate the
flexibility of using *_clones which is now gone):
perl instance1 {
# This is a large branch => I put higher values for max_clones,
start_clones etc but keeping the pool static to avoid reloading the
settings from the DB on module instantiation
}
perl instance2 {
# This is another (slightly modified) script which takes care of
special circumstances and is connected to a different DB
}
# ... and now using the wonderful ulang functionality I do the
following in ... say accounting
switch "%{NAS-IP-Address}" {
case '10.250.15.1' {
instance1
}
case '10.250.17.192' {
instance2
}
}
This doesn't work with 2.1.4 although my perl is compiled with
ithreads and multiplicity etc
On 15.04.2009, at 11:11, Alan DeKok wrote:
Borislav Dimitrov wrote:
I just subscribed so I won't be able to quote properly but I hope at
least the message is associated with the right thread (I found it
on the
web archive of the mailing list). I've been using FreeRADIUS for
about 4
year now and it is a wonderful product - there's no question why
you're
No 1! For the past years of using and developing rlm_perl modules for
FreeRADIUS, I've only been astonished and happy because of the new
functionalities etc that the development team have been adding to the
new releases. This all ended with this crippling-
... of the rlm_perl module?
The changes were made to simplify the code. Having *two* thread pool
managers is inefficient, and unnecessary.
Can you say *exactly* what your issue is with these changes?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
