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 per
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.
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 co
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 th
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
mak
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 i
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 satisfie
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 th
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
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 t
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 i
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 t
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 circumsta
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 threa
> >> It should be running one Perl thread per system thread. The
server
> >> core already manages min/max spare threads, idle threads, etc.
> > I hope this implementation will satisfy Borislav too. Will he be
> > able to
> > instantiate different perl scripts for different needs?
> >
> > So, whe
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 manages
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 af
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 next
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
On Wed, Apr 22, 2009 at 12:23 PM, 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 sho
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
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 yo
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 yo
26 matches
Mail list logo
