rlm_perl behavior

[Borislav Dimitrov]

Yes this was the main reason but there are others too.

С поздрави

Борислав Димитров
e-mail: b.dimitrov at ngsystems.net
GSM: 0889 28 54 57
NG Systems
Лавеле 32, ет: 4,
София, България



On 15.04.2009, at 11:06, Apostolos Pantsiopoulos wrote:

> Were you also depending on the rlm_perl threads to
> make connections to multiple DBs? I know that I can
> make an array of db handlers within one perl thread
> and use them interchangeably, but the functionality
> I had in the 2.0.x release where every perl thread
> had its own connection to the DBs and the queries
> were executed simultaneously was much better. I am getting
> the feeling that I am loosing in parallelism.
>
> I understand that there may some benefits in the current
> implementation (2.1.x) such as less threads, smaller memory
> footprint etc. but why change something that has been tested
> and working in the first place?
>
>
>
>
> Borislav Dimitrov wrote:
>> Hello,
>> 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-
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>
> -- 
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html