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

[Klaus Darilion]

Indeed, it is even more complex :-)

So, depending on the Event type - e.g. presence allows sending NOTIFY 
without waiting for the response, but xcap-diff does not allow it - we 
would have to queue notifications and then have a dedicated NOTIFYer who 
performs the notifications. I do not think that a single NOTIFYer can be 
blocked, as UDP is always non-blocking and TCP is now non-blocking too.

regards
Klaus

On 27.03.2012 16:43, Anca Vamanu wrote:
> 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
>>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev