Hello Laura,
I made a patch with the changes required for a pure DB_ONLY mode.
You can find it on master branch.
Any feedback is very welcomed.
Regards,
Marius
________________________________
From: laura testi <lau.testi(a)gmail.com>
To: Henning Westerholt <henning.westerholt(a)1und1.de>de>; "Bucur, Marius
Ovidiu" <marius.bucur(a)1and1.ro>
Cc: "sr-users(a)lists.sip-router.org" <sr-users(a)lists.sip-router.org>
Sent: Thursday, July 21, 2011 11:08 AM
Subject: Re: [SR-Users] xcap server - http load–balancer: xcap authentication problem
Hi Marius,
thank you for your answer. It would e nice if you can provide a pure
DB mode that disable completely subscription hashtable and presentity
hashtable in cache but only working with DB. Otherwise it can be still
problematic with our test case. Because when the one presence server
receives a PUBLISH from one presentity, it will looks-up the local
subscription hastable then DB for the active watchers's contact to
send notify and update the CSEQ in the subscription hastable/DB. But
if there is any subscription of this presentity is in the remote
subscription hashtable (another presence server) , the CSEQ of this
subscription in hashtable will not be updated.
Thanks!
Best Regards,
Laura
Hello Laura,
Thank you for your email and providing the full
test-case.
You are right, there is a certain issue (that is also mentioned in another thread -
"DB_ONLY mode in presence module").
The thing is, that there are two caches
- a subscription hashtable, maintaining information
about active subscripions
- a presentity hashtable, maintaining information about presence
entities
(presentities, entities that send PUBLISH requests)
The db_only mode acts only on the first type of cache -
subscriptions.
It really makes sense having the db_only mode act also on the second cache (the presentity
cache), hence your usecase is >very common.
There are some cases when you only need a db_only mode only for subscriptions (like when
PUBLISH requests are >generated precisely on each presence server machines) but of
course I think it is a good compromise to disable caching >also for the
"presentity" table when running in db_only mode.
I will make a patch this evening with this change, and
commit it on the master branch.
If anyone has other suggestions, please let me know.
Cheers,
Marius
On Wed, Jul 20, 2011 at 1:11 PM, laura testi <lau.testi(a)gmail.com> wrote:
Hi Marius,
Thank you very much for your explanations. I see your answer only in
the list. Here I copy to here for the convenience:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hello,
In the DB_ONLY mode, every SUBSCRIBE request will trigger a database
operation immediately (either insert or update).
Also, the SUBSCRIPTION will always be matched from the database.
It behaves exactly as the name implies (write-through).
If it doesn't then that is a bug. Can you please tell me more about
the scenario you are using?
Is there any usecase in which you can see the subscription in memory
but not in the active_watchers table?
Regards,
Marius
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The scenario wehave tested is like that we have multiple presence
servers and a share DB in the separate DB server. The incoming
SIP/SIMPLE traffic are dispatched with the Dispatcher. The problem we
found is that the write-through mechanism guarantee the
active_watchers cache is synched to DB immediately when it change like
your explanation; but not vice versa. For example, when the
active_watchers table in DB is changed by one presence server via the
same write-through mechanism, it seems there is not possible to
populate the changes in DB back to cache of another presence server.
That means the cache in the different presence servers are not
synchronized. It will required complex replications to have cache in
synched.
I'll try to explain it by the following use case we have tested:
Test Environments:
- SIP clients: (jitsi)
- user1 (has user2 as a contact, user 2 is watcher of user1 with the state=1)
- user2 (has user1 as a contact, user 1 is watcher of user2 withe
the state=1)
- SIP server (kamailio3.1.4)
- 1 x dispatcher (routing based call id)
- 2 x presence servers (PS1 and PS2)
- DB server:
- 1 x backend DB server for SIP servers
Test Case (user2 is already login and the subscription to user1 is in
one of the 2 PS cache and in DB):
1) when user1 login, it send SUBSCRIBE presence event of user2 to the
Dispatcher, and Dispatcher forward it to PS1
- PS1 write the subscription (user1->user2 with CSEQ=1) to
active_watchers cache
then active_wacthers table in DB immediately (write-through)
- PS1 send the NOTIFY of the user2 presence status to user1 and
increase the CSEQ by 1 (becomes 2) to
both cache and DB (write-through)
2) user1 receive the NOTIFY and check the CSEQ (the first time), and
update the user2's status
3) user2 change it's presence status and send the PUBLISH to the
dispatcher, and Dispatcher forward it to PS2
- PS2 call handle_publish, it look-ups to the local cache for the
active subscription and not found,
then fallback to DB and found it, it increase the CSEQ by 1
(becomes 3 in DB) and send the NOTIFY
to user1 with CSEQ=3 (here is the problem, the CSEQ of the same
subscription in the PS1's cache is still equal 2)
4) the user1's client receive the NOTIFY and check the CSEQ if it's
greater than the previous one, it's,
then update the Presence Status of user2
5) user2 change it's presence status again, this time the Dispatcher
forward the PUBLISH to PS1
- PS1 call handle_publish, it look-ups to the local cache for the
active subscription and found it with CSEQ=2!
It increase the CSEQ by 1 (becomes 3 in the cache and update the
value to DB), and send the NOTIFY
to user1 with CSEQ=3 again.
6) user1's client receive the NOTIFY and check the CSEQ if it's
greater than the previous one, it's not,
then it ignore it, the presen status of user2 is not updated in the
user1's client!
This problem can be solved if we have pure DB mode only. In that case,
the CSEQ is always increased for the successive NOTIFY of the same
subscription.
It would be nice to keep the new Write-Through DB Mode in the
presence module, and add a Pure DB mode, just like the usrloc module?
Just in case, in usrloc module, it miss the fallback to DB mode but
has write-through and pure db mode ;-)
Best Regards,
Laura
On Fri, Jul 15, 2011 at 4:58 PM, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
On Friday 15 July 2011, laura testi wrote:
we have checked the presence extension for
DB_MODE only in the master
branch. But it's not complete DB_ONLY mode, it seems that it still uses
the cache for active_watchers in write through mode. Is there any reason
for it? That can still make problem for the scalability for the multiple
presence servers, because if an presence event (either SIP or XCAP) of an
active subscription in the cache of one presence server, goes to another
presence server, can still cause the problem even the DB is sync with the
cache.
Hello Marius,
maybe you can comment a bit on this?
Thanks and best regards,
Henning
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users