[sr-dev] New module DMQ_SYNC and patch for DMQ

Charles Chance charles.chance at sipcentric.com
Thu Oct 30 09:35:07 CET 2014


That makes a lot of sense, actually.

So another question: should there be a single syncing module (i.e.
dmq_sync) for all modules which are sensitive and/or export all
functionality through their API, or one per module (e.g. dmq_usrloc...)?
 I was actually thinking of it, but couldn't get to a clear conclusion
before ...

Overall, I am not sure if making white or black is the best. I see it more
of a per case situation.

For example, usrloc is a standalone component by itself, with registrar
being the interface to kamailio.cfg, then pua_usrloc or pua_reginfo being
the presence events publishing. Being such a component used in various
directions, I think it should stay rather independent, not getting extra
stuff inside, but other components can be built on top of its exported API.

On the other hand, just adding a new module for each other module that
wants to notify via dmq could be an unnecessary overhead.

So, at this moment, I would say, if the module has everything that is
needed exported via API, the dmq can be done as separate module. Also, if
the module is very sensitive, I would suggest the same approach (e.g., I
wouldn't like to see it inside tm module, if someone thinks of dmq-ing
transactions, but rather a separate module or part of tmx).

Cheers,
Daniel


On 29/10/14 19:38, Charles Chance wrote:

Maybe others can offer their advice as to which is the preferred way to go?



On 28 October 2014 14:40, Andrey Rybkin <rybkin.a at bks.tv> wrote:

>  Thought about to add this functionality to the module. If this approach
> seems to be more correct, then I can move my code in a module, but, in my
> opinion, it is not very correct.
>  ________________________________
>    Andrey Rybkin
> JID: rybkin.a at bks.tv
>  E-Mail: rybkin.a at bks.tv
>
>    2014-10-28 16:46 GMT+03:00 Alex Hermann <alex at speakup.nl>:
>
>> On Tuesday 28 October 2014, Андрей Рыбкин wrote:
>> > Module DMQ_SYNC:
>> >   The module add replication between multiple servers via DMQ module.
>> >    Currently only usrloc replications.
>>
>> I think some decision should be made on where syncing code should be
>> placed.
>> The htable module has dmq sync integrated, now you introduce a module
>> dedicated to syncing via dmq.
>>
>> I have no strong preference, but am against different implementations
>> depending on the module. So i would prefer either dmq-sync integrated into
>> each module, or one dmq_sync module. Not a combination of both.
>>
>>
>> > TODO:
>> >  1.  dialog replications.
>> >  2.  bugfixes.
>> >
>> > Patch fo DMQ:
>> >  1. add  find_dmq_node_uri function  to API
>> >      dmq_node_t* find_dmq_node_uri(str* uri)
>>
>> >  2. add  init_callback  to  dmq_peer
>> >      int init_callback()
>>
>> Except for the broken indenting, this seems equal to my code. If it is
>> mine,
>> and the code is useful, please cherry-pick the relevant commits so
>> authorship
>> is retained.
>>
>> --
>> Greetings,
>>
>> Alex Hermann
>>
>>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>


www.sipcentric.com

Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.

_______________________________________________
sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda


_______________________________________________
sr-dev mailing list
sr-dev at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
www.sipcentric.com

Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, 
Birmingham Science Park, Birmingham B7 4BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141030/84067395/attachment-0001.html>


More information about the sr-dev mailing list