26 Feb
2010
26 Feb
'10
11:38 a.m.
summarizing, I am going to merge pipelimit as separate module for now.
The future will dedice if both worth to keep or one will take over the
other.
Cheers,
Daniel
On 02/04/2010 05:15 AM, Ovidiu Sas wrote:
The major disadvantage that I encounter with modparam
(in the current
ratelimit module) is related to changes done via rpc/fifo/mi: on
server restart, all these changes are lost (unless the config is also
updated).
I much prefer to have the ability to change the db and then perform a
reload. This will ensure the same behavior on server restart.
One may argue that it is the same with modparam, but the difference is
that changing the config and performing changes via rpc/fifo/mi
interface are two independent operations vs changing the db and after
that perform a reload, which is a cause/effect operation, ensure
synchronicity between server restarts.
I also much prefer to have the ability to create a generic config file
and customize the deployment via the db.
Maybe keeping the ratelimit as is and having the pipelimit with db
only config will be the best solution for now. It time, we will see
which one has more traction.
Regards,
Ovidiu Sas
On Wed, Feb 3, 2010 at 6:15 PM, Andrei Pelinescu-Onciul
<andrei(a)iptel.org> wrote:
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
On Feb 02, 2010 at 13:41, Ovidiu
Sas<osas(a)voipembedded.com> wrote:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hello Henning,
Having both method of initialization will just complicate the code.
When the module parameters are parsed, the shared memory is not
available and therefor all the module rate limit parameters will need
to be cached into the memory until the shared memory is available.
The shared memory is available for module params (recent change).
New code needs to be added to deal with conflicts
when both method of
initialization are provided: init via db and init via module
parameters.
Having the ratelimit configured via module parameters is forcing
changing the config file every time the default rate limits are
changed.
One could change them via rpc/fifo/mi at runtime, without restart.
Using the simple db_text module has a lot of
advantages:
- db_text is available for all platforms;
- the database is used only during init, after that the database is
no longer used and therefor there is no impact on performance;
- the rate limits are stored in human readable text file;
- a database reload feature can be added and the default rate limits
can be changed without touching the config file and server restart
will keep the new settings.
These are just my observation from using heavily the existing ratelimit module.
If specifying the rate limits in the config file is a must, I would
recommend keeping both modules and moving the common code into a
library:
- ratelimit with config init
- pipelimit with db init
I would prefer having the option of using modpram+rpc method instead of
db.
Andrei