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 <[email protected]> wrote:
> 
> 
> 
>> On 16 Aug 2023, at 14:05, Fred Posner <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 
>>>>>> 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 <[email protected]> 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 <[email protected]> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 15 Aug 2023, at 14:59, Daniel-Constantin Mierla 
>>>>>>>>> <[email protected]> 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 [email protected]
>>>>>>> _______________________________________________
>>>>>>> Kamailio (SER) - Development Mailing List
>>>>>>> To unsubscribe send an email to [email protected]
>>>>>> 
>>>>>> -- 
>>>>>> 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 [email protected]
>>>>> 
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Development Mailing List
>>>>> To unsubscribe send an email to [email protected]
>>>> _______________________________________________
>>>> Kamailio (SER) - Development Mailing List
>>>> To unsubscribe send an email to [email protected]
>>> 
>>> _______________________________________________
>>> Kamailio (SER) - Development Mailing List
>>> To unsubscribe send an email to [email protected]
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> To unsubscribe send an email to [email protected]
> 
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> To unsubscribe send an email to [email protected]
_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to [email protected]

Reply via email to