28 Oct
2014
28 Oct
'14
12:21 p.m.
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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
28 Oct
28 Oct
1:19 p.m.
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(a)bks.tv> wrote:
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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
_______________________________________________
sr-dev mailing list
sr-dev(a)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.
2:55 p.m.
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.
--
Greetings,
Alex Hermann
2:46 p.m.
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
3:09 p.m.
On 28 Oct 2014 13:46, "Alex Hermann" <alex(a)speakup.nl> wrote:
On Tuesday 28 October 2014, Андрей Рыбкин wrote:
placed.
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 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.
--
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.
3:40 p.m.
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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl>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
29 Oct
29 Oct
7:38 p.m.
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(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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl>nl>:
--
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.
On Tuesday 28 October 2014, Андрей Рыбкин wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
10:10 p.m.
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(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(a)bks.tv <mailto:rybkin.a@bks.tv>
E-Mail: rybkin.a(a)bks.tv <mailto:rybkin.a@bks.tv>
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl
<mailto:alex@speakup.nl>>:
On Tuesday 28 October 2014, Андрей Рыбкин wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
www.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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
30 Oct
30 Oct
9:35 a.m.
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(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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl>nl>:
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
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)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.
On Tuesday 28 October 2014, Андрей Рыбкин wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
13 Nov
13 Nov
10:15 a.m.
Hello, Charles!
Can you commit my patch to your DMQ module?
________________________________
Andrey Rybkin
JID: rybkin.a(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-29 21:38 GMT+03:00 Charles Chance <charles.chance(a)sipcentric.com>om>:
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(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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl>nl>:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Tuesday 28 October 2014, Андрей Рыбкин wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
10:56 a.m.
Hi Andrey,
I will get to it later today.
Cheers,
Charles
On 13 Nov 2014 09:15, "Andrey Rybkin" <rybkin.a(a)bks.tv> wrote:
Hello, Charles!
Can you commit my patch to your DMQ module?
________________________________
Andrey Rybkin
JID: rybkin.a(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-29 21:38 GMT+03:00 Charles Chance <charles.chance(a)sipcentric.com>om>:
--
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.
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(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(a)bks.tv
E-Mail: rybkin.a(a)bks.tv
2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl>nl>:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
11:09 p.m.
Hi Andrey,
I have now committed the DMQ updates to master branch.
Regards,
Charles
On 13 November 2014 09:56, Charles Chance <charles.chance(a)sipcentric.com>
wrote:
Hi Andrey,
I will get to it later today.
Cheers,
Charles
On 13 Nov 2014 09:15, "Andrey Rybkin" <rybkin.a(a)bks.tv> wrote:
> Hello, Charles!
>
> Can you commit my patch to your DMQ module?
>
> ________________________________
> Andrey Rybkin
> JID: rybkin.a(a)bks.tv
> E-Mail: rybkin.a(a)bks.tv
>
> 2014-10-29 21:38 GMT+03:00 Charles Chance <charles.chance(a)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(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(a)bks.tv
>>> E-Mail: rybkin.a(a)bks.tv
>>>
>>> 2014-10-28 16:46 GMT+03:00 Alex Hermann <alex(a)speakup.nl>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(a)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(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>
--
*Charles Chance*
Managing Director
t. 0121 285 4400 m. 07932 063 891
--
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.
3451
days inactive
3467
days old
11 comments
5 participants
participants (5)
-
Alex Hermann -
Andrey Rybkin -
Charles Chance -
Daniel-Constantin Mierla -
Андрей Рыбкин