[sr-dev] git:master: modules_k/presence Fixed DB Storage Modes

[Anca Vamanu]

Hi Klaus,


I thought about these race conditions also.

The problem is a bit more complicated because with UDP actually we can 
not assure that the requests will be received in the same order by the 
destination even if they are send by the same process. As an example, we 
have the problem with the Notify that is received before 200OK for 
Subscribe in some cases even if they are generated by the same process. 
So I don't know if there is much point in implementing a more rigorous 
synchronization considering this..

Of course for TCP it would make more sense and the 100% sure solution is 
indeed the second one that you proposed - having a specialized process 
to send out the Notifies. But this is the most complicated, as actually 
we might need a pool of processes not to get blocked because one 
destination is unreachable for example. And then we would need the 
divide the Notifies per destination to actually ensure that one process 
receives all the Notifies for a certain destination.

The first solution that you propose is not that difficult to implement - 
to have an array of locks and take the corresponding lock when updating 
a certain dialog ( hash on a callid for example). And do an update 
immediatelly after search and both under the lock. This would not insure 
a 100% synchronization but better then now.

Regards,
Anca


On 03/27/2012 02:46 PM, Klaus Darilion wrote:
> Hi Anca!
>
> I just wondered if race conditions are handled properly (DB-only mode)
>
> E.g. there are 2 PUBLISH for a certain presentity (or a PUBLISH and
> reSUBSCRIBE) received almost at the same time. Processing of these
> PUBLISH can happen in different processes (or servers), thus when
> generating the NOTIFY I think it can happen that both processes try to
> UPDATE the cseq and e.g. use the wrong cseq when sending the NOTIFYs.
> Reading the cseq and increasing the cseq should happen in a transaction
> with a row lock.
>
> Another approach would be to have a dedicated NOTIFYer process which
> takes care of sending NOTIFYs. On reSUBSCRIBE or PUBLISH a presentity
> gets marked for updates (e.g. in a separate table) and the NOTIFYer
> polls this table and sends the NOTIFYs in proper order.
>
> What do you think about that?
>
> regards
> Klaus
>
> On 15.02.2012 13:45, Anca Vamanu wrote:
>> Module: sip-router
>> Branch: master
>> Commit: ae86ca3611398ce365ac4a1776ff0c7e95476bbe
>> URL:    http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ae86ca3611398ce365ac4a1776ff0c7e95476bbe
>>
>> Author: Anca Vamanu<anca.vamanu at 1and1.ro>
>> Committer: Anca Vamanu<anca.vamanu at 1and1.ro>
>> Date:   Wed Feb 15 13:39:55 2012 +0200
>>
>> modules_k/presence Fixed DB Storage Modes
>>
>> - removed db_mode and fallback2db parameters and added two new
>>     parameters: subs_db_mode and publ_cache
>> - fixed and extended the storage modes for subscriptions: Memory Only,
>>     Write Through, Write Back, DB Only
>> - publ_cache parameter offers the possibility to disable publish cache
>> - some other fixes:
>>       - delete subscription only for 481 or 408 reply for Notify
>>       - call child_init also for main process (no shutdown DB flush was
>>         being performed)
>>
>> ---
>>
>>    modules_k/presence/README                 |  190 ++++++-----
>>    modules_k/presence/bind_presence.c        |    4 +-
>>    modules_k/presence/bind_presence.h        |    4 +-
>>    modules_k/presence/doc/presence_admin.xml |  127 +++++---
>>    modules_k/presence/doc/presence_devel.xml |    2 +-
>>    modules_k/presence/event_list.c           |    2 +-
>>    modules_k/presence/event_list.h           |    2 +-
>>    modules_k/presence/hash.c                 |   25 +--
>>    modules_k/presence/hash.h                 |    2 +-
>>    modules_k/presence/notify.c               |  253 ++++++---------
>>    modules_k/presence/notify.h               |    2 +-
>>    modules_k/presence/presence.c             |  108 +++----
>>    modules_k/presence/presence.h             |   19 +-
>>    modules_k/presence/presentity.c           |   30 +--
>>    modules_k/presence/presentity.h           |    2 +-
>>    modules_k/presence/publish.c              |   52 ++--
>>    modules_k/presence/publish.h              |    2 +-
>>    modules_k/presence/subscribe.c            |  495 +++++++++++++++++++----------
>>    modules_k/presence/subscribe.h            |    7 +-
>>    modules_k/presence/utils_func.c           |    2 +-
>>    modules_k/presence/utils_func.h           |    2 +-
>>    modules_k/pua/hash.h                      |    1 +
>>    22 files changed, 736 insertions(+), 597 deletions(-)
>>
>> Diff:   http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=ae86ca3611398ce365ac4a1776ff0c7e95476bbe
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>