15 Aug
2023
15 Aug
'23
3:59 p.m.
Module: kamailio
Branch: master
Commit: b612f07918212ae872c092562a9e0527a89f7f9e
URL: https://github.com/kamailio/kamailio/commit/b612f07918212ae872c092562a9e052…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2023-08-15T14:57:15+02:00
htable: docs for rpc htable.dmqsync
---
Modified: src/modules/htable/doc/htable_admin.xml
---
Diff:
https://github.com/kamailio/kamailio/commit/b612f07918212ae872c092562a9e052…
Patch:
https://github.com/kamailio/kamailio/commit/b612f07918212ae872c092562a9e052…
---
diff --git a/src/modules/htable/doc/htable_admin.xml
b/src/modules/htable/doc/htable_admin.xml
index 84f20e7b328..c7d68847f04 100644
--- a/src/modules/htable/doc/htable_admin.xml
+++ b/src/modules/htable/doc/htable_admin.xml
@@ -1778,6 +1778,25 @@ kamcmd htable.listTables
...
kamcmd htable.stats
...
+</programlisting>
+ </section>
+ <section id="htable.rpc.dmqsync">
+ <title>
+ <function
moreinfo="none">htable.dmqsync</function>
+ </title>
+ <para>
+ Perform a MdQ sync action.
+ </para>
+ <para>
+ Name: <emphasis>htable.dmqsync</emphasis>
+ </para>
+ <para>
+ Example:
+ </para>
+<programlisting format="linespecific">
+...
+kamcmd htable.dmqsync
+...
</programlisting>
</section>
16 Aug
16 Aug
12:04 a.m.
There are many scenarios I’ve encountered where I wanted this ability…
One would be a temporary loss of connectivity on a DMQ member node, which results in its
htable being out of sync with the other member nodes.
Another would be an accidental local flush.
More scenarios would be applicable as well.
—fred
On Aug 15, 2023, at 8:21 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
On 15 Aug 2023, at 14:59, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
htable: docs for rpc htable.dmqsync
When do you need to run this and why? Just curious :-)
I thought it was happening magically in the background.
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org 
12:08 a.m.
Well, if I understand Olle's argument correctly, the reason you want this is because
it is not, in fact, "magically happening in the background", and perhaps if it
were, that would be an acceptable fix as well. ;-)
On Aug 15, 2023, at 5:04 PM, Fred Posner
<fred(a)pgpx.io> wrote:
There are many scenarios I’ve encountered where I wanted this ability…
One would be a temporary loss of connectivity on a DMQ member node, which results in its
htable being out of sync with the other member nodes.
Another would be an accidental local flush.
More scenarios would be applicable as well.
—fred
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On Aug 15, 2023, at 8:21 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On 15 Aug 2023, at 14:59, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
htable: docs for rpc htable.dmqsync
When do you need to run this and why? Just curious :-)
I thought it was happening magically in the background.
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org 
11:01 a.m.
So if a node is down and comes back up, do you want to force the sync at startup?
Or is this a safetybelt you want cron to run regurlarly? If so, that sounds like a bug…
Sync is a hard problem.
/O
On 15 Aug 2023, at 23:08, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, if I understand Olle's argument correctly, the reason you want this is because
it is not, in fact, "magically happening in the background", and perhaps if it
were, that would be an acceptable fix as well. ;-)
On Aug 15, 2023, at 5:04 PM, Fred Posner
<fred(a)pgpx.io> wrote:
There are many scenarios I’ve encountered where I wanted this ability…
One would be a temporary loss of connectivity on a DMQ member node, which results in its
htable being out of sync with the other member nodes.
Another would be an accidental local flush.
More scenarios would be applicable as well.
—fred
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On Aug 15, 2023, at 8:21 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On 15 Aug 2023, at 14:59, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
htable: docs for rpc htable.dmqsync
When do you need to run this and why? Just curious :-)
I thought it was happening magically in the background.
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
1:45 p.m.
A restart (hard down) would resync assuming your config is set to initially sync.
DMQ is push oriented, not pull. So a soft down, for example a brief connectivity issue,
will result in the node missing the pushes.
It’s not so much a bug, just the way of design. Some other DMQ systems also work similarly
and the burden/responsibility is notI placed on the sender to “own” that a member receives
and processed the message.
This can be done periodically as a safety belt and or when a node notices a connectivity
issue may have occurred.
It can also not be done for scenarios when it’s not necessary for nodes to be exactly in
sync all the time.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
On Aug 16, 2023, at 3:03 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
So if a node is down and comes back up, do you want to force the sync at startup?
Or is this a safetybelt you want cron to run regurlarly? If so, that sounds like a bug…
Sync is a hard problem.
/O
On 15 Aug 2023, at 23:08, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, if I understand Olle's argument correctly, the reason you want this is because
it is not, in fact, "magically happening in the background", and perhaps if it
were, that would be an acceptable fix as well. ;-)
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On Aug
15, 2023, at 5:04 PM, Fred Posner <fred(a)pgpx.io> wrote:
There are many scenarios I’ve encountered where I wanted this ability…
One would be a temporary loss of connectivity on a DMQ member node, which results in its
htable being out of sync with the other member nodes.
Another would be an accidental local flush.
More scenarios would be applicable as well.
—fred
On Aug 15, 2023, at 8:21 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
> On 15 Aug 2023, at 14:59, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
>
> htable: docs for rpc htable.dmqsync
When do you need to run this and why? Just curious :-)
I thought it was happening magically in the background.
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
2:55 p.m.
Great feedback. Thanks.
Do we have all of this covered in the docs? That we’re using PUSH over UDP in many cases,
so things can get out of sync
if we have network downtime (as an example).
/O
On 16 Aug 2023, at 12:45, Fred Posner
<fred(a)pgpx.io> wrote:
A restart (hard down) would resync assuming your config is set to initially sync.
DMQ is push oriented, not pull. So a soft down, for example a brief connectivity issue,
will result in the node missing the pushes.
It’s not so much a bug, just the way of design. Some other DMQ systems also work
similarly and the burden/responsibility is notI placed on the sender to “own” that a
member receives and processed the message.
This can be done periodically as a safety belt and or when a node notices a connectivity
issue may have occurred.
It can also not be done for scenarios when it’s not necessary for nodes to be exactly in
sync all the time.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
On Aug 16, 2023, at 3:03 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
So if a node is down and comes back up, do you want to force the sync at startup?
Or is this a safetybelt you want cron to run regurlarly? If so, that sounds like a bug…
Sync is a hard problem.
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On 15 Aug 2023, at 23:08, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, if I understand Olle's argument correctly, the reason you want this is because
it is not, in fact, "magically happening in the background", and perhaps if it
were, that would be an acceptable fix as well. ;-)
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org > On Aug 15, 2023, at 5:04 PM, Fred Posner
<fred(a)pgpx.io> wrote:
There are many scenarios I’ve encountered where I wanted this ability…
One would be a temporary loss of connectivity on a DMQ member node, which results in its
htable being out of sync with the other member nodes.
Another would be an accidental local flush.
More scenarios would be applicable as well.
—fred
> On Aug 15, 2023, at 8:21 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
>
>
>
>> On 15 Aug 2023, at 14:59, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
>>
>> htable: docs for rpc htable.dmqsync
>
>
> When do you need to run this and why? Just curious :-)
>
> I thought it was happening magically in the background.
>
> /O
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
3:05 p.m.
if you look at the module doc, all reference is to broadcast and the only mention of a
pull type communication is on the initial notify.
There is no function for “pull,” so as I see your point here, this is a decently
documented module that does not indicate any presence of a pull method (only broadcast and
handle received message).
I personally don’t feel this documentation is missing the specific aspects of pull vs push
as no pull is implied.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
On Aug 16, 2023, at 6:57 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
Great feedback. Thanks.
Do we have all of this covered in the docs? That we’re using PUSH over UDP in many cases,
so things can get out of sync
if we have network downtime (as an example).
/O
On 16 Aug 2023, at 12:45, Fred Posner
<fred(a)pgpx.io> wrote:
A restart (hard down) would resync assuming your config is set to initially sync.
DMQ is push oriented, not pull. So a soft down, for example a brief connectivity issue,
will result in the node missing the pushes.
It’s not so much a bug, just the way of design. Some other DMQ systems also work
similarly and the burden/responsibility is notI placed on the sender to “own” that a
member receives and processed the message.
This can be done periodically as a safety belt and or when a node notices a connectivity
issue may have occurred.
It can also not be done for scenarios when it’s not necessary for nodes to be exactly in
sync all the time.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On Aug
16, 2023, at 3:03 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
So if a node is down and comes back up, do you want to force the sync at startup?
Or is this a safetybelt you want cron to run regurlarly? If so, that sounds like a bug…
Sync is a hard problem.
/O
On 15 Aug 2023, at 23:08, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, if I understand Olle's argument correctly, the reason you want this is because
it is not, in fact, "magically happening in the background", and perhaps if it
were, that would be an acceptable fix as well. ;-)
>> On Aug 15, 2023, at 5:04 PM, Fred Posner <fred(a)pgpx.io> wrote:
>
> There are many scenarios I’ve encountered where I wanted this ability…
>
> One would be a temporary loss of connectivity on a DMQ member node, which results in
its htable being out of sync with the other member nodes.
>
> Another would be an accidental local flush.
>
> More scenarios would be applicable as well.
>
> —fred
>
>> On Aug 15, 2023, at 8:21 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
>>
>>
>>
>>> On 15 Aug 2023, at 14:59, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
>>>
>>> htable: docs for rpc htable.dmqsync
>>
>>
>> When do you need to run this and why? Just curious :-)
>>
>> I thought it was happening magically in the background.
>>
>> /O
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
3:11 p.m.
On 16 Aug 2023, at 14:05, Fred Posner
<fred(a)pgpx.io> wrote:
if you look at the module doc, all reference is to broadcast and the only mention of a
pull type communication is on the initial notify.
There is no function for “pull,” so as I see your point here, this is a decently
documented module that does not indicate any presence of a pull method (only broadcast and
handle received message).
I personally don’t feel this documentation is missing the specific aspects of pull vs
push as no pull is implied.
Thank you for your response. Then I’m happy! Have fun at Cluecon!
/O
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
On Aug 16, 2023, at 6:57 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
Great feedback. Thanks.
Do we have all of this covered in the docs? That we’re using PUSH over UDP in many cases,
so things can get out of sync
if we have network downtime (as an example).
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On 16 Aug 2023, at 12:45, Fred Posner
<fred(a)pgpx.io> wrote:
A restart (hard down) would resync assuming your config is set to initially sync.
DMQ is push oriented, not pull. So a soft down, for example a brief connectivity issue,
will result in the node missing the pushes.
It’s not so much a bug, just the way of design. Some other DMQ systems also work
similarly and the burden/responsibility is notI placed on the sender to “own” that a
member receives and processed the message.
This can be done periodically as a safety belt and or when a node notices a connectivity
issue may have occurred.
It can also not be done for scenarios when it’s not necessary for nodes to be exactly in
sync all the time.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org > On Aug 16, 2023, at 3:03 AM, Olle E.
Johansson <oej(a)edvina.net> wrote:
So if a node is down and comes back up, do you want to force the sync at startup?
Or is this a safetybelt you want cron to run regurlarly? If so, that sounds like a bug…
Sync is a hard problem.
/O
> On 15 Aug 2023, at 23:08, Alex Balashov <abalashov(a)evaristesys.com> wrote:
>
> Well, if I understand Olle's argument correctly, the reason you want this is
because it is not, in fact, "magically happening in the background", and perhaps
if it were, that would be an acceptable fix as well. ;-)
>
>>> On Aug 15, 2023, at 5:04 PM, Fred Posner <fred(a)pgpx.io> wrote:
>>
>> There are many scenarios I’ve encountered where I wanted this ability…
>>
>> One would be a temporary loss of connectivity on a DMQ member node, which results
in its htable being out of sync with the other member nodes.
>>
>> Another would be an accidental local flush.
>>
>> More scenarios would be applicable as well.
>>
>> —fred
>>
>>> On Aug 15, 2023, at 8:21 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
>>>
>>>
>>>
>>>> On 15 Aug 2023, at 14:59, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
>>>>
>>>> htable: docs for rpc htable.dmqsync
>>>
>>>
>>> When do you need to run this and why? Just curious :-)
>>>
>>> I thought it was happening magically in the background.
>>>
>>> /O
>>> _______________________________________________
>>> Kamailio (SER) - Development Mailing List
>>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
3:16 p.m.
Would be more fun if you were here.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
On Aug 16, 2023, at 7:13 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
On 16 Aug 2023, at 14:05, Fred Posner
<fred(a)pgpx.io> wrote:
if you look at the module doc, all reference is to broadcast and the only mention of a
pull type communication is on the initial notify.
There is no function for “pull,” so as I see your point here, this is a decently
documented module that does not indicate any presence of a pull method (only broadcast and
handle received message).
I personally don’t feel this documentation is missing the specific aspects of pull vs
push as no pull is implied.
Thank you for your response. Then I’m happy! Have fun at Cluecon!
/O
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org On Aug
16, 2023, at 6:57 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
Great feedback. Thanks.
Do we have all of this covered in the docs? That we’re using PUSH over UDP in many cases,
so things can get out of sync
if we have network downtime (as an example).
/O
On 16 Aug 2023, at 12:45, Fred Posner
<fred(a)pgpx.io> wrote:
A restart (hard down) would resync assuming your config is set to initially sync.
DMQ is push oriented, not pull. So a soft down, for example a brief connectivity issue,
will result in the node missing the pushes.
It’s not so much a bug, just the way of design. Some other DMQ systems also work
similarly and the burden/responsibility is notI placed on the sender to “own” that a
member receives and processed the message.
This can be done periodically as a safety belt and or when a node notices a connectivity
issue may have occurred.
It can also not be done for scenarios when it’s not necessary for nodes to be exactly in
sync all the time.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
>> On Aug 16, 2023, at 3:03 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
>
> So if a node is down and comes back up, do you want to force the sync at startup?
>
> Or is this a safetybelt you want cron to run regurlarly? If so, that sounds like a
bug…
>
> Sync is a hard problem.
> /O
>
>> On 15 Aug 2023, at 23:08, Alex Balashov <abalashov(a)evaristesys.com> wrote:
>>
>> Well, if I understand Olle's argument correctly, the reason you want this is
because it is not, in fact, "magically happening in the background", and perhaps
if it were, that would be an acceptable fix as well. ;-)
>>
>>>> On Aug 15, 2023, at 5:04 PM, Fred Posner <fred(a)pgpx.io> wrote:
>>>
>>> There are many scenarios I’ve encountered where I wanted this ability…
>>>
>>> One would be a temporary loss of connectivity on a DMQ member node, which
results in its htable being out of sync with the other member nodes.
>>>
>>> Another would be an accidental local flush.
>>>
>>> More scenarios would be applicable as well.
>>>
>>> —fred
>>>
>>>> On Aug 15, 2023, at 8:21 AM, Olle E. Johansson <oej(a)edvina.net>
wrote:
>>>>
>>>>
>>>>
>>>>> On 15 Aug 2023, at 14:59, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
>>>>>
>>>>> htable: docs for rpc htable.dmqsync
>>>>
>>>>
>>>> When do you need to run this and why? Just curious :-)
>>>>
>>>> I thought it was happening magically in the background.
>>>>
>>>> /O
>>>> _______________________________________________
>>>> Kamailio (SER) - Development Mailing List
>>>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
>>> _______________________________________________
>>> Kamailio (SER) - Development Mailing List
>>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
>>
>> --
>> Alex Balashov
>> Principal Consultant
>> Evariste Systems LLC
>> Web: https://evaristesys.com
>> Tel: +1-706-510-6800
>>
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
408
days inactive
409
days old
9 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Fred Posner -
Olle E. Johansson