htable + dmq: sht_rm_name does not replicate

[marcinkowalczyk]

Description

I'm using htable DMQ replication to relicate call details over kamailio nodes. I've noticed that htable items are not removed when sht_rm_name is called inside script

Troubleshooting

Reproduction

put in script:

$sht(cidParam=>$ci::callee_socket) = $sas;
sht_rm_name("cidParam", "sw", "$ci");

make a call and see what gets replicated

ngrep -W byline -d any '"htname":"cidParam"' | grep action

When htable item is removed from htable using CLI removal it's replicated
{"action":3,"htname":"cidParam","cname":"x","mode":0}.

Additional Information

• Kamailio Version - output of kamailio -v

version: kamailio 5.4.1 (x86_64/linux) 09fd6a
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 09fd6a
compiled on 11:07:49 Sep  1 2020 with gcc 4.8.5

• Operating System:

CentOS7

Linux 3.10.0-1127.18.2.el7.x86_64 #1 SMP Sun Jul 26 15:27:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[miconda]

Only re operation was replicated. I pushed a commit in master to replicate sw, test and see if works as expected.

[marcinkowalczyk]

Hi Dan,

No luck. I did cherry-pick to local 5.4.1 but this should not change anything.
Pre call:

node 0

[root@v0p1356-dispatcher htable]# kamcmd htable.dump cidParam
[root@v0p1356-dispatcher htable]#

node1
[root@V0P1376-dispatcher-02 htable]# kamcmd htable.dump cidParam
[root@V0P1376-dispatcher-02 htable]#

make a call on node0

[root@v0p1356-dispatcher htable]#  ngrep -W byline -d any  htab  |grep actio
{"action":2,"htname":"cidParam","cname":"6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::callee_socket","type":2,"strval":"udp:10.3.96.231:5060","mode":1}2.(...<D._c.1...
{"action":2,"htname":"prefixParam","cname":"record::007815","type":0,"intval":0,"mode":1}ccig.pl....<D._.
{"action":2,"htname":"cidParam","cname":"6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::init","type":0,"intval":1,"mode":1} ...<D._.0U.....
{"action":2,"htname":"cidParam","cname":"6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::reinvited","type":0,"intval":1,"mode":1}<L.....BD._Y....
{"action":2,"htname":"cidParam","cname":"6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::reinvited","type":0,"intval":1,"mode":1}.0.....JD._...1.
{"action":6,"htname":"cidParam","type":2,"strval":,"mode":0}w..j....JD._..,4
{"action":6,"htname":"cidParam","type":2,"strval":,"mode":0}.F.....p..39.Y}.

post call on node0

[root@v0p1356-dispatcher htable]# kamcmd htable.dump cidParam
[root@v0p1356-dispatcher htable]#

post call on node1

[root@V0P1376-dispatcher-02 htable]# kamcmd htable.dump cidParam
{
        entry: 228814
        size: 1
        slot: {
                {
                        name: 6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::callee_socket
                        value: udp:10.3.96.231:5060
                        type: str
                }
        }
}
{
        entry: 745232
        size: 1
        slot: {
                {
                        name: 6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::reinvited
                        value: 1
                        type: int
                }
        }
}
{
        entry: 1027817
        size: 1
        slot: {
                {
                        name: 6d9eed7818bab5bb4b607ece7c329c83@10.3.96.231:5060::init
                        value: 1
                        type: int
                }
        }
}
[root@V0P1376-dispatcher-02 htable]#

[miconda]

Dicovered that the value was not set for the replication operation in this case. I just pushed another commit to htable module to fix it, can you try it?

[marcinkowalczyk]

Hi Dan,

Works fine. I've tested it backporting on 5.4.1.

[marcinkowalczyk]

One more thing,

Seems
kamcmd htable.flush <table_name>
is not replicted too - is it intended?

[miconda]

Yes, RPC commands were targeting the administrative commands and if they didn't use internally other runtime operations, they were not replicated. Now, of course, new features can be added over the time, the best via pull requests.

Closing this one, the commits added what was requested.