rlm_perl behavior

[Borislav Dimitrov]

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