[SR-Users] usrloc, timer process and cache cleanup

[Daniel-Constantin Mierla]

Hello,

On 12/23/11 1:39 PM, Andreas Granig wrote:
> Hi,
>
> On 12/23/2011 12:28 AM, Daniel-Constantin Mierla wrote:
>>> If someone is messing with the db, kamailio shouldn't try to correct
>>> admin mistakes.
>> It was just an example, I haven't gone to all corner cases that can
>> happen from human or (self or different) application errors. There were
>> couple of similar reports in the past, related to conflicts of
>> insert/update, update/insert, delete/update a.s.o. cases, so I proposed
>> to go for a portable solution, not for one which valid to a db driver
>> only -- configurable or not, is different thing than the specific topic.
> Of course you can never rule out admin errors or application errors, but
> anyways I'll highly favor a more resilient approach.

I encountered several cases when things can go bad at database layer 
while doing cross replication along with t_replicate(). Finding a 
solution would be a good thing. The fact is that these situations should 
be corner cases, so there has to be a solution not impact the normal 
operation mode.
>
> I've tried to reproduce the most obvious scenario, which is registering
> a subscriber, delete it from the underlying db table, then re-register
> again. The expiry value in the cache is refreshed, but it's never
> written back to the db table. There are most likely other, more subtle
> scenarios, and our customers approved that they didn't mess with the db
> manually. The state was always CS_SYNC and Flags was 0.
>
> I don't know the details of the srdb layer, but probably it's possible
> to find a way to return the "rows affected" after an update in order to
> know whether to try an insert afterwards. Would be possible with mysql,
> not sure about pgsql, oracle, dbtext etc. We'll take a look how we could
> tackle that.
Mysql has affected row and it is exported by db_mysql module, not sure 
about the other drivers.

>
> I don't think that a log message would help very much, because kamailio
> won't know about the missing entry in the db (unless you evaluate the
> result of the update), at least in this particular case.
Yes, kamailio does not know, I know, seems it is what we try to solve -- 
first how to make it aware and then do some actions (like writing a log 
message).

Perhaps the best for the moment is to detect at startup and rely on db 
api capabilities and use replace/affected_rows a.s.o. when they are 
available, in the best efficient order -- a module parameter can give 
admins the power to decide over the auto-detect.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda