Hi Juha, Thanks for your reply. First prominent doubt that I have is; when I am using LCR in db_only mode why does openser try to load the table while starting up? The scenario is as follows: I had 50 rows in LCR table and started openser and it started properly and also routed the calls properly according to the values in lcr and gw table. Now I just appended more 40,000 rows to this table and again the routing worked properly as per my lcr table. This behaviour was correct as I was using query only mode. I did not need any restart or any fifo reload command. Only when I restarted my openser, the openser again died as it was trying load the lcr table while starting. Could this be a bug in lcr module as I am not sure whats happening. I tried increasing MAX_NO_OF_LCRS but even that did not help. Somebody please help if poosible.
Thanks,
w/regards, jayesh
----- Original Message ---- From: Juha Heinanen jh@tutpro.com To: Jayesh Nambiar voip_freak@yahoo.co.in Cc: openser users@openser.org Sent: Tuesday, 26 December, 2006 10:58:01 PM Subject: [Users] LCR db_only mode problem
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] the error messages you get are coming from this statement:
if (lcr_dbf.query(dbh, NULL, 0, NULL, lcr_cols, 0, 4, 0, &res) < 0) { LOG(L_ERR, "lcr_reload_gws(): Failed to query lcr data\n"); lcr_dbf.close(dbh); return -1; }
i don't know which kind of memory db queries reserve. if shared memory, you can start openser with larger -m parameter value. if pkg memory, you need to edit PKG_MEM_POOL_SIZE in config.h and recompile openser.
with lots of lcr entries and no caching, performance may be bad. if you use caching then you need to increase value of
#define MAX_NO_OF_LCRS 256
in lcr_mod.c and recompile lcr module. increasing MAX_NO_OF_LCRS means that more shared memory will be used so you may also need to start openser with larger -m parameter value.
-- juha
Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php
currently lcr module always loads gw and lcr tables into memory. there used to be no db_mode variable in the early days of the module. gws were always loaded into memory and lcr entries were never loaded.
then caching mode was added along with loading of lcr entries into memory. at that time db_mode variable was also introduced, but it only affects load_gws function. i guess db_mode was added just in case a bug is found in caching version of load_gws and people need to go back to old behavior.
caching mode was added, because it turned out that load_gws database query was far too slow if there is a large number of gws/lcr entries. so even if you would manage to make lcr module to work in db_only mode, it would not do you any good. also, there is no db only version of from_gw/to_gw functions.
my conclusion of this messy situation is that i'll remove db_mode altogether from lcr module.
-- juha
Hi Juha,
maybe it will be a good idea to have in lcr module the DB serial loading (as usrloc does now when using cache). This will solve the problem of too much private memory required at start up.
regards, bogdan
Juha Heinanen wrote:
currently lcr module always loads gw and lcr tables into memory. there used to be no db_mode variable in the early days of the module. gws were always loaded into memory and lcr entries were never loaded.
then caching mode was added along with loading of lcr entries into memory. at that time db_mode variable was also introduced, but it only affects load_gws function. i guess db_mode was added just in case a bug is found in caching version of load_gws and people need to go back to old behavior.
caching mode was added, because it turned out that load_gws database query was far too slow if there is a large number of gws/lcr entries. so even if you would manage to make lcr module to work in db_only mode, it would not do you any good. also, there is no db only version of from_gw/to_gw functions.
my conclusion of this messy situation is that i'll remove db_mode altogether from lcr module.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu writes:
maybe it will be a good idea to have in lcr module the DB serial loading (as usrloc does now when using cache). This will solve the problem of too much private memory required at start up.
lcr module was not designed for applications where there are tens of thousands of different prefixes to choose gateways for. it was designed to be able to choose different gateways at country code/area code levels where number of different prefixes is at most hundreds.
i suggest writing another module for an application that requires support for tens of thousands of prefixes.
-- juha