sr-dev

sr-dev@lists.kamailio.org

44307 discussions

[tracker] Comment added: Database and cache inconsistency with registrar module / usrloc

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - Database and cache inconsistency with registrar module / usrloc User who did this - Henning Westerholt (henningw) ---------- (There is an error in my previous comment, i refer of course to the UPDATE case.) If i remember correctly (has been some time..) then i think you need only to change the DB API call in modules_k/usrloc/ucontact.c:db_insert_ucontact(..) from ul_dbf.insert(..) to ul_dbf.insert_update(..), and then change in the same file in the update_ucontact function the call of 'db_update_ucontact(_c)' to 'db_insert_ucontact(_c)'. Then all contact update calls will use the insert on duplicate key update function, and all inserts will use this function as well. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment33 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Database and cache inconsistency with registrar module / usrloc

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - Database and cache inconsistency with registrar module / usrloc User who did this - Ronald Voermans (voermans) ---------- - I'm not that an expert when it comes to patching. Can you guide me how to change this? - I think the reason for the inconsistency is that Kamailio couldn't reach the MySQL server anymore, due to some network-issues (it's in a lab). At the time the MySQL was available again (after about an hour or so), I restarted Kamailio. That's the only thing that has happened. Of course I can't tell exactly when the inconsistency has occured (cannot find anything in the logs), but that's what I guess. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment32 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Database and cache inconsistency with registrar module / usrloc

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - Database and cache inconsistency with registrar module / usrloc User who did this - Henning Westerholt (henningw) ---------- For this reason we replaced the INSERT in this case (in our internal version) with an INSERT ON DUPLICATE KEY UPDATE. This will create the appropriate state regardless of the previous content. The DB API export this functionality as well, its not a complicated patch. But the main question for me is, why does your location table does not contain the previous registered entries anymore? Are they expired somehow, or were there an error during insertion? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment31 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Task changed: Database and cache inconsistency with registrar module / usrloc

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#41 - Database and cache inconsistency with registrar module / usrloc User who did this: Andrei Pelinescu-Onciul (andrei) Category: Core -> usrloc (k) Assigned To: Andrei Pelinescu-Onciul -> Daniel-Constantin Mierla, Henning Westerholt More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

CVS:commitlog: sip_router/mem f_malloc.c

by Andrei Pelinescu-Onciul

andrei 2010/03/12 14:50:06 CET SER CVS Repository Modified files: mem f_malloc.c Log: mem: fix f_malloc big fragments bug In some situation, when dealing with several big free fragments (>16k) f_malloc would wrongly choose a fragment with a smaller size then requested. This would create the impression that someone arbitrarily overwrites the memory. First symptoms were some tls crashes reported by Klaus Darilion klaus.darilion(a)nic.at. Reproduced using the malloc_test module. (backported from sip-router, commit c7099d0a1204120277cf662cc05ab35180d89538) Revision Changes Path 1.29 +3 -3 sip_router/mem/f_malloc.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/mem/f_malloc.c.dif…

14 years, 10 months

[tracker] Assignee added: Database and cache inconsistency with registrar module / usrloc

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#41 - Database and cache inconsistency with registrar module / usrloc User who did this - Ronald Voermans (voermans) http://sip-router.org/tracker/index.php?do=details&task_id=41 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Task opened: Database and cache inconsistency with registrar module / usrloc

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Ronald Voermans (voermans) Attached to Project - sip-router Summary - Database and cache inconsistency with registrar module / usrloc Task Type - Bug Report Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Hi, I'm using Kamailio 3.0.0. I'm using the 'location' table to store registered contacts (save("location")), and i'm using db_mode = 1 (from usrloc). However, currently I have only 13 records in my location table, and 121 registered clients (checked via kamctl ul show --brief). When a client re-registers, I do a save("location") and an UPDATE is sent to MySQL. But there isn't any record to update, so nothing gets updated. I think that if an update has no matches (ie nothing gets updated), an INSERT must be perfomed in the database, so there is an consistency between the two. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

git:master: mem: fix real_used stats for realloc

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 75c1e9a735c693a6985a7a1786116b5fe4044fd9 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=75c1e9a… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Fri Mar 12 12:16:16 2010 +0100 mem: fix real_used stats for realloc A realloc that shrank an allocation accounted twice for the fragment overhead. Basically each shrinking realloc would introduce an error in the real_used mem stats, between 8 bytes (f_malloc, no debugging, 32 bits) and up to 96 bytes (q_malloc with debugging, 64 bits). This bug concerns only the accounting part. It does not cause any memory leak or any real runtime problem. It was introduced in commit fb9d6e50 (2005). --- mem/f_malloc.c | 4 +++- mem/q_malloc.c | 7 +++++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/mem/f_malloc.c b/mem/f_malloc.c index 2c05fe6..49c4b7a 100644 --- a/mem/f_malloc.c +++ b/mem/f_malloc.c @@ -491,7 +491,9 @@ void* fm_realloc(struct fm_block* qm, void* p, unsigned long size) fm_split_frag(qm, f, size); #endif #if defined(DBG_F_MALLOC) || defined(MALLOC_STATS) - qm->real_used-=(orig_size-f->size-FRAG_OVERHEAD); + /* fm_split frag already adds FRAG_OVERHEAD for the newly created + free frag, so here we only need orig_size-f->size for real used */ + qm->real_used-=(orig_size-f->size); qm->used-=(orig_size-f->size); #endif }else if (f->size<size){ diff --git a/mem/q_malloc.c b/mem/q_malloc.c index 09cb5c7..04c6dc9 100644 --- a/mem/q_malloc.c +++ b/mem/q_malloc.c @@ -562,8 +562,11 @@ void* qm_realloc(struct qm_block* qm, void* p, unsigned long size) #else if(split_frag(qm, f, size)!=0){ #endif - /* update used sizes: freed the spitted frag */ - qm->real_used-=(orig_size-f->size-FRAG_OVERHEAD); + /* update used sizes: freed the splited frag */ + /* split frag already adds FRAG_OVERHEAD for the newly created + free frag, so here we only need orig_size-f->size for real used + */ + qm->real_used-=(orig_size-f->size); qm->used-=(orig_size-f->size); }

14 years, 10 months

handling failed t_relay() when multiple usr locations

by Iñaki Baz Castillo

Hi, imagine this case: - bob is registered from multiple locations: a) a responding UDP/TCP location b) a non responding TCP location (it crashed) - alice calls bob - Kamailio gets both branches from location table and runs t_relay(). - t_relay() replies "true" as location a) is responding. However in this case it would be useful to realize that the second location (unreachable TCP location) doesn't work, and being TCP it's safe to remove it from location table. AFAIK (correct me if I'm wrong) there is some script function to remove user locations, but there is no way to use it in the example above (am I wrong?). As a suggestion, there could be a usrloc option to remove TCP contacts from location table when t_relay() fails, perhaps in conjunction with some new flag for t_relay() function. Is there any better aproach for this purpose? -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 10 months

git:master: test/ unit Added support for running the tests if kamailio was built instead of ser

by Marius Zbihlei

Module: sip-router Branch: master Commit: a0b247b8cd596b3032270316a2184a04c9cff917 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a0b247b… Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro> Date: Fri Mar 12 11:54:25 2010 +0200 test/unit Added support for running the tests if kamailio was built instead of ser Support was added by checking what executable exists in the $SR_DIR path --- test/unit/include/common | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/test/unit/include/common b/test/unit/include/common index 14077d5..d918496 100644 --- a/test/unit/include/common +++ b/test/unit/include/common @@ -7,6 +7,15 @@ CTLRC="$CTL_DIR/kamctlrc" CTL="$CTL_DIR/kamctl" DBCTL="$CTL_DIR/kamdbctl" BIN="$SR_DIR/ser" +if [ -f $SR_DIR/ser ] ; then + BIN="$SR_DIR/ser" +else + if [ -f $SR_DIR/kamailio ] ; then + BIN="$SR_DIR/kamailio" + else + echo "WARNING Binary not found!" + fi +fi KILL="killall -15 $BIN" # test directory relative to root TEST_DIR="test/unit"

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev