### 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 ```
Only `re` operation was replicated. I pushed a commit in master to replicate `sw`, test and see if works as expected.
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]#
```
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?
Hi Dan,
Works fine. I've tested it backporting on 5.4.1.
One more thing,
Seems `kamcmd htable.flush <table_name>` is not replicted too - is it intended?
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.
Closed #2573.