On Wed, Apr 22, 2009 at 12:23 PM, Alan DeKok al...@deployingradius.com wrote:
Apostolos Pantsiopoulos wrote:
If any changes are to be made to the current
implementation to support multiple interpreters (one per thread)
would they show up in a 2.1.x release or a future one (2.2.x or something)?
I think yes. In my current config (2.1.8) it works fine.
--
---
Apostolos Pantsiopoulos
Kinetix Tele.com R D
email: r...@kinetix.gr
---
On 3/3/2010 4:26 μμ, Alexandr Kovalenko wrote:
On Wed, Apr 22, 2009 at 12:23
On Apr 22, 2009, at 7:25 PM, Borislav Dimitrov wrote:
On 22.04.2009, at 13:23, Alan DeKok wrote:
Apostolos Pantsiopoulos wrote:
If any changes are to be made to the current
implementation to support multiple interpreters (one per thread)
would they show up in a 2.1.x release or a future one
If any changes are to be made to the current
implementation to support multiple interpreters (one per thread)
would they show up in a 2.1.x release or a future one (2.2.x or something)?
Meyers, Dan wrote:
It should be running one Perl thread per system thread. The
server
core already
Apostolos Pantsiopoulos wrote:
If any changes are to be made to the current
implementation to support multiple interpreters (one per thread)
would they show up in a 2.1.x release or a future one (2.2.x or something)?
They will show up in the next release, whatever that is.
i.e. next after
On 22.04.2009, at 13:23, Alan DeKok wrote:
Apostolos Pantsiopoulos wrote:
If any changes are to be made to the current
implementation to support multiple interpreters (one per thread)
would they show up in a 2.1.x release or a future one (2.2.x or
something)?
They will show up in the
It should be running one Perl thread per system thread. The
server
core already manages min/max spare threads, idle threads, etc.
snip
I hope this implementation will satisfy Borislav too. Will he be
able to
instantiate different perl scripts for different needs?
So, when do I
Yes, that would be great. One perl interpreter
per freeradius thread, that is. And I suppose the
CLONE function would work again as expected (i.e. each
freeradius thread would have its own perl interpreter and
each script relaying on this interpreter would have its
own connection to the DB). And
From my point of view we should have pool of perl clones per each
module instance.
This way we could have multiple perl instances (each with its own perl
script to run).
Limiting on perl clone or interp per server thread will limit the
multiple instances feature of rlm_perl.
Again playing
Boian Jordanov wrote:
From my point of view we should have pool of perl clones per each
module instance.
Yes.
This way we could have multiple perl instances (each with its own perl
script to run).
Yes.
Limiting on perl clone or interp per server thread will limit the
multiple
Alan DeKok wrote:
Boian Jordanov wrote:
From my point of view we should have pool of perl clones per each
module instance.
Yes.
This way we could have multiple perl instances (each with its own perl
script to run).
Yes.
Limiting on perl clone or interp per server thread will limit
I hope this implementation will satisfy Borislav too. Will he be
able to
instantiate different perl scripts for different needs?
So, when do I start testing :)
Hi,
Yes, being able to instantiate and use several rlm_perl instances with
different scripts to take care of different
Borislav Dimitrov wrote:
Sacrificing the *_clones flexibility for lower memory footprint, better
performance and more importantly code is certainly worth doing it, if
people are still able to have multiple rlm_perl instances.
If we update the module to have one Perl thread per system thread,
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
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
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
Yes this was the main reason but there are others too.
С поздрави
Борислав Димитров
e-mail: b.dimit...@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
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
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
Apostolos Pantsiopoulos wrote:
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?
A quest to make it better. If we were satisfied
Borislav Dimitrov wrote:
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):
Ah... OK. That was *not* the intent of the change. I'll take a look
at fixing it for the
Hi,
On 15.04.2009, at 20:31, Alan DeKok wrote:
Borislav Dimitrov wrote:
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):
Ah... OK. That was *not* the intent of
Apostolos Pantsiopoulos wrote:
Does this mean that in the new behavior I have one perl instance
(thread) shared by all the radius threads? And if so, are all the radius
requests being processed sequentially by it? Doesn't this degrade
the performance?
Possibly, yes.
Or, the module could
Alan DeKok wrote:
Apostolos Pantsiopoulos wrote:
I noticed that the following directives :
...
for perl were not present in the file after the compiling.
Are these directives obsolete?
Yes. The server already has a thread management system. Adding
another one for Perl is unnecessary.
Alan DeKok wrote:
Apostolos Pantsiopoulos wrote:
I noticed that the following directives :
...
for perl were not present in the file after the compiling.
Are these directives obsolete?
Yes. The server already has a thread management system. Adding
another one for Perl is unnecessary.
I updated my server from 2.0.x to 2.1.4
and found out that the rlm_perl config now resides
in the /module directory.
I noticed that the following directives :
max_clones = 10
start_clones = 5
min_spare_clones = 1
max_spare_clones = 5
max_request_per_clone
Apostolos Pantsiopoulos wrote:
I noticed that the following directives :
...
for perl were not present in the file after the compiling.
Are these directives obsolete?
Yes. The server already has a thread management system. Adding
another one for Perl is unnecessary.
Also, in my perl
27 matches
Mail list logo
