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 <and...@iptel.org> wrote: > On Feb 02, 2010 at 13:41, Ovidiu Sas <o...@voipembedded.com> wrote: >> 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 > _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
