Hello!
There is a ```delete from `location` where `expires`<'XYZ' AND `expires`<>'1970-01-01 03:00:00'``` query that runs before every time when insert, update or delete for location table is executed. The last query from the provided example was unsuccessful before the second last query deleted the corresponding record.
The test was made on the Kamailio v5.4.0. Usrloc module configuration is: ``` modparam("usrloc", "db_url", DATABASE_URL) modparam("usrloc", "timer_interval", 10) modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", FLB_NATB) modparam("usrloc", "db_timer_clean", 1) ```
The test phone I was using - Zoiper softphone updates registration 5 seconds before the expiration. The first registration was at 15:04:43. The following update was at 15:05:38. Following DB queries were executed:
``` 529486 Query delete from `location` where `expires`<'2020-08-24 15:04:45' AND `expires`<>'1970-01-01 03:00:00' 529485 Query insert into `location` (`username`,`contact`,`expires`,`q`,`callid`,`cseq`,`flags`,`cflags`,`user_agent`,`received`,`socket`,`last_modified`,`ruid`,`reg_id`,`server_id`,`connection_id`,`keepalive`,`partition` ) values ('300-test','sip:300-test@192.168.0.105:56022;rinstance=5dd76a9c6cb94169;transport=tcp','2020-08-24 15:05:43',-1.000000,'DQzsJiW2Cpjs66s88IkOMQ..',2,0,0,'Z 3.15.40006 rv2.8.20','sip:XXX.XXX.XXX.XXX:56317;transport=tcp','tcp:172.16.30.216:5060','2020-08-24 15:04:43','uloc-5f43acc8-1f59-1',0,0,1,0,0)
529486 Query delete from `location` where `expires`<'2020-08-24 15:04:55' AND `expires`<>'1970-01-01 03:00:00'
529486 Query delete from `location` where `expires`<'2020-08-24 15:05:05' AND `expires`<>'1970-01-01 03:00:00'
529486 Query delete from `location` where `expires`<'2020-08-24 15:05:15' AND `expires`<>'1970-01-01 03:00:00'
529486 Query delete from `location` where `expires`<'2020-08-24 15:05:25' AND `expires`<>'1970-01-01 03:00:00'
529486 Query delete from `location` where `expires`<'2020-08-24 15:05:35' AND `expires`<>'1970-01-01 03:00:00'
529486 Query delete from `location` where `expires`<'2020-08-24 15:05:45' AND `expires`<>'1970-01-01 03:00:00' 529485 Query update `location` set `expires`='2020-08-24 15:06:38',`q`=-1.000000 ,`cseq`=3,`flags`=0,`cflags`=0,`user_agent`='Z 3.15.40006 rv2.8.20',`received`='sip:XXX.XXX.XXX.XXX:56317;transport=tcp',`path`=NULL,`socket`='tcp:172.16.30.216:5060',`methods`=NULL,`last_modified`='2020-08-24 15:05:38',`callid`='DQzsJiW2Cpjs66s88IkOMQ..',`instance`=NULL,`reg_id`=0,`server_id`=0,`connection_id`=1,`keepalive`=0,`contact`='sip:300-test@192.168.0.105:56022;rinstance=5dd76a9c6cb94169;transport=tcp' where `ruid`='uloc-5f43acc8-1f59-1' ```
Reducing timer_interval value to 3 seconds corrected the behavior for me. But is it possible to run ```delete from `location` where `expires`<'XYZ' AND `expires`<>'1970-01-01 03:00:00'``` query not before but after queries that manage particular registrations are executed?
Thank you!
The delete is from timer process, independent of processing REGISTER requests that are handled in another processes. If you need some delay when removing contact for db_mode=2, look at the parameter:
* https://www.kamailio.org/docs/modules/stable/modules/usrloc.html#usrloc.p.rm...
Otherwise, adding locking/syncronization will introduce a bottleneck, decreasing the performances. And overall, even it would be serialized, I think it is better to do delete first, so the insert/update is going to be faster, not having key constraints checking on invalid records. Even more, the phones usually have to re-register several seconds before expiration of their last registration, otherwise network transmission can add delay and the old record is removed anyhow, typically is 20-30sec before expiration when the expire value is at least a few minutes. In your case, it seems it is 1 minute.
If you need to discuss further, then join sr-users@lists.kamailio.org, there are a lot of options that allows tuning usrloc for specific use cases. Here we track bugs in the C code and for now look more like a design decision than a bug. If proves to be a bug after discussions, then it can be reopened.
Closed #2455.