i have seen emails about expired records not removed from database, but i could not find the thread.
i'm not sure if it is related, but today i noticed too that there is an old record in my location table which has expired couple of hours ago. the record does not show up with ul_dump command, so it has been removed from memory. usrloc db_mode=1.
what could cause the record not be removed? is it a bug in cleaner process? i have usrloc timer_procs=2.
-- juha
Juha Heinanen writes:
i'm not sure if it is related, but today i noticed too that there is an old record in my location table which has expired couple of hours ago. the record does not show up with ul_dump command, so it has been removed from memory. usrloc db_mode=1.
after restart of kamailio, the expired record disappeared after some time after restart, but looks like it would never have disappeared without restart.
-- juha
Hello,
On 4/8/13 10:13 AM, Juha Heinanen wrote:
Juha Heinanen writes:
i'm not sure if it is related, but today i noticed too that there is an old record in my location table which has expired couple of hours ago. the record does not show up with ul_dump command, so it has been removed from memory. usrloc db_mode=1.
after restart of kamailio, the expired record disappeared after some time after restart, but looks like it would never have disappeared without restart.
I started a discussion with subject "SIP contact matching - location db ops" at the end of March, following a report on tracker.
The problem showed up very likely because the UA changed the call-id -- there are different matching algorithms, but seems they are only for in-memory lookup, the database operations (update/delete) seem to be always matching on contact address and call-id. That means in memory records are fine, but database can get some old records not deleted.
After analysis the best solution seems to be to match on ruid for database operations, because matching on path will be very inefficient (contact or contact+callid should still be quite ok). But I didn't have any time to code it, not sure I will find some spare time during the next two weeks, maybe someone else can look into it -- it has to review if ruid is updated in any case (which I don't think so, but should be double-checked) and the big part will be actually testing, as coding should even simplify the sql queries. I haven't looked at DB only mode to see if it requires some special care.
Cheers, Daniel
Cheers, Daniel
Daniel-Constantin Mierla writes:
After analysis the best solution seems to be to match on ruid for database operations, because matching on path will be very inefficient (contact or contact+callid should still be quite ok).
makes sense to use ruid for that. since this would again be db operation on ruid, it would make sense to introduce index on ruid. especially db only mode would suffer a lot without the index.
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen