[sr-dev] git:master: modules_k/rls: RLS full-state NOTIFY requests now sent by notifier process(es)

Peter Dunkley peter.dunkley at crocodile-rcs.com
Fri Apr 20 10:31:50 CEST 2012


Hi Klaus,

By wrapping the queries into a DB transaction do you mean something
along the lines of doing BEGIN/COMMIT/ROLLBACK in PostgreSQL around some
sets of transactions?  For example, the query selecting records with the
updated flag set and subsequent query to unset the flag?

If so this would be good to prevent multiple servers attempting to do
the same set of updates at the same time.  Is there an easy (and DB
independent) way to do this Kamailio?

I am not sure I understand the issue about auto_reconnect?

Thanks,

Peter

On Fri, 2012-04-20 at 10:03 +0200, Klaus Darilion wrote:

> Hi Peter!
> 
> I remember we had some discussion that same queries may be wrapped into 
> a DB transaction to avoid inconsistencies when using multiple presence 
> servers.
> 
> I just wonder if this is now the case or not. Because then, 
> auto_reconnect in the DB module must be disabled as it may happen that 
> the connection is closed/connected during a transaction.
> 
> regards
> Klaus
> 
> On 18.04.2012 18:36, Peter Dunkley wrote:
> > Module: sip-router
> > Branch: master
> > Commit: dff68160e4decc43f2da8948ea03bc4d469ded96
> > URL:    http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=dff68160e4decc43f2da8948ea03bc4d469ded96
> >
> > Author: Peter Dunkley<peter.dunkley at crocodile-rcs.com>
> > Committer: Peter Dunkley<peter.dunkley at crocodile-rcs.com>
> > Date:   Wed Apr 18 17:29:32 2012 +0100
> >
> > modules_k/rls: RLS full-state NOTIFY requests now sent by notifier process(es)
> >
> > - Also modified the notifier process stuff to only work when in
> >    DB only mode.  This is because the full-state handling stuff
> >    in the notifier processes relies on DB only mode.
> > - Leaving the full-state stuff outside of the notifier process
> >    didn't work because there was a row update race between the
> >    notifier process and non-notifier process when full-state and non-
> >    full-state NOTIFY requests were generated at the same time.
> > - This ensures that (with default options) you get at most one NOTIFY
> >    (or set of NOTIFYs when splitting large NOTIFYs is enabled) per
> >    5s per watcher from RLS.
> > - It also helps spread out the NOTIFY generation load more evenly
> >    across time.
> >
> > ---
> >
> >   modules_k/rls/README            |    6 ++
> >   modules_k/rls/doc/rls_admin.xml |    8 ++
> >   modules_k/rls/resource_notify.c |  175 +++++++++++++++++++++++++++++++++++++--
> >   modules_k/rls/rls.c             |   25 ++++--
> >   modules_k/rls/rls.h             |    3 +
> >   modules_k/rls/rls_db.c          |   20 ++++-
> >   modules_k/rls/subscribe.c       |   40 ++++++----
> >   7 files changed, 240 insertions(+), 37 deletions(-)
> >
> > Diff:   http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=dff68160e4decc43f2da8948ea03bc4d469ded96
> >
> > _______________________________________________
> > sr-dev mailing list
> > sr-dev at lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120420/cd461844/attachment.htm>


More information about the sr-dev mailing list