Hi all!
Module DMQ_SYNC: The module add replication between multiple servers via DMQ module. Currently only usrloc replications. 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() ______________________________ Andrey Rybkin JID: rybkin.a@bks.tv E-Mail: rybkin.a@bks.tv
Hi,
I believe Alex Hermann had dialog sync in hand. He was away for a while, but was going to resume upon his return. Maybe he can confirm?
I can add the patch to dmq itself (I still have to commit my patch for forced socket). Maybe others can comment/advise regarding the new dmq_sync part?
Regards,
Charles On 28 Oct 2014 11:21, "Андрей Рыбкин" rybkin.a@bks.tv wrote:
Hi all!
Module DMQ_SYNC: The module add replication between multiple servers via DMQ module. Currently only usrloc replications. TODO:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- add init_callback to dmq_peer int init_callback()
Andrey Rybkin JID: rybkin.a@bks.tv E-Mail: rybkin.a@bks.tv
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Tuesday 28 October 2014, Charles Chance wrote:
I believe Alex Hermann had dialog sync in hand. He was away for a while, but was going to resume upon his return. Maybe he can confirm?
I'm back, but i had to stop working on the dialog syncing because it took too much time. I encountered too many problems (crashes) related to (the interactions between) the dialog, dmq and tm (uac) modules. Tracking them all down took too long.
I'll commit the fixes i have accumulated for these modules, and maybe try again later this year.
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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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.
On 28 Oct 2014 13:46, "Alex Hermann" alex@speakup.nl wrote:
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.
Personally, I would prefer to see syncing integrated with each module that requires it (as with htable). That way, replication can be implemented in the most appropriate way for that module, instead of making assumptions about how other modules wish to replicate internal state.
Ultimately, whichever way is agreed upon, a single choice is better from the outset.
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@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann alex@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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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
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@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@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann alex@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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@bks.tv mailto:rybkin.a@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@bks.tv <mailto:rybkin.a@bks.tv> E-Mail: rybkin.a@bks.tv <mailto:rybkin.a@bks.tv> 2014-10-28 16:46 GMT+03:00 Alex Hermann <alex@speakup.nl <mailto:alex@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@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-devwww.sipcentric.com http://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 list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@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@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann alex@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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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@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@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello, Charles!
Can you commit my patch to your DMQ module?
________________________________ Andrey Rybkin JID: rybkin.a@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-29 21:38 GMT+03:00 Charles Chance charles.chance@sipcentric.com:
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@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@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann alex@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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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@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 list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Andrey,
I will get to it later today.
Cheers, Charles On 13 Nov 2014 09:15, "Andrey Rybkin" rybkin.a@bks.tv wrote:
Hello, Charles!
Can you commit my patch to your DMQ module?
Andrey Rybkin JID: rybkin.a@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-29 21:38 GMT+03:00 Charles Chance charles.chance@sipcentric.com:
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@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@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann alex@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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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@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 list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Andrey,
I have now committed the DMQ updates to master branch.
Regards, Charles
On 13 November 2014 09:56, Charles Chance charles.chance@sipcentric.com wrote:
Hi Andrey,
I will get to it later today.
Cheers, Charles On 13 Nov 2014 09:15, "Andrey Rybkin" rybkin.a@bks.tv wrote:
Hello, Charles!
Can you commit my patch to your DMQ module?
Andrey Rybkin JID: rybkin.a@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-29 21:38 GMT+03:00 Charles Chance charles.chance@sipcentric.com :
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@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@bks.tv E-Mail: rybkin.a@bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann alex@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:
- dialog replications.
- bugfixes.
Patch fo DMQ:
- add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri)
- 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@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 list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Alex Hermann -
Andrey Rybkin -
Charles Chance -
Daniel-Constantin Mierla -
Андрей Рыбкин