```
CC (gcc) [M db_redis.so] redis_table.o
CC (gcc) [M db_redis.so] db_redis_mod.o
CC (gcc) [M db_redis.so] redis_connection.o
In file included from ../../lib/srdb1/../../core/ut.h:42,
from ../../lib/srdb1/db_key.h:31,
from ../../lib/srdb1/db.h:43,
from db_redis_mod.h:26,
from redis_table.c:25:
redis_table.c: In function 'db_redis_parse_keys':
../../lib/srdb1/../../core/dprint.h:303:8: warning: 'table_name.len' may be used uninitialized in this function [-Wmaybe-uninitialized]
303 | fprintf(stderr, "%2d(%d) %s: %.*s%s" fmt, \
| ^~~~~~~
redis_table.c:494:9: note: 'table_name.len' was declared here
494 | str table_name;
| ^~~~~~~~~~
In file included from ../../lib/srdb1/../../core/ut.h:42,
from ../../lib/srdb1/db_key.h:31,
from ../../lib/srdb1/db.h:43,
from db_redis_mod.h:26,
from redis_table.c:25:
../../lib/srdb1/../../core/dprint.h:303:8: warning: 'table_name.s' may be used uninitialized in this function [-Wmaybe-uninitialized]
303 | fprintf(stderr, "%2d(%d) %s: %.*s%s" fmt, \
| ^~~~~~~
redis_table.c:494:9: note: 'table_name.s' was declared here
494 | str table_name;
| ^~~~~~~~~~
redis_table.c:581:38: warning: 'table' may be used uninitialized in this function [-Wmaybe-uninitialized]
581 | table->types = type_target = type;
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
CC (gcc) [M db_redis.so] redis_dbase.o
make[3]: 'libsrdb2.so.1.0' is up to date.
make[3]: 'libsrdb1.so.1.0' is up to date.
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2169
#2057 # Description
The documentation for the dispatcher module indicates that maxload = 0 indicates no call limit for the call load distribution algorithm. However, when filling in the XAVP list for additional destinations, mode 10 does not handle the case where maxload = 0, so there are never any additional destinations in this case. This means that there is no failover if the original destination fails.
Issue #800 also addressed a maxload = 0 issue, but did not address the XAVP list.
### Possible Solutions
The following patch resolves the issue for me:
```diff
diff -ru a/modules/dispatcher/dispatch.c b/modules/dispatcher/dispatch.c
--- a/modules/dispatcher/dispatch.c 2020-04-23 10:41:32.414130450 -0500
+++ b/modules/dispatcher/dispatch.c 2020-04-23 10:42:11.738154578 -0500
@@ -2273,6 +2273,7 @@
}
/* max load exceeded per destination */
if(rstate->alg == DS_ALG_CALLLOAD
+ && idx->dlist[i].attrs.maxload != 0
&& idx->dlist[i].dload >= idx->dlist[i].attrs.maxload) {
continue;
}
@@ -2294,6 +2295,7 @@
}
/* max load exceeded per destination */
if(rstate->alg == DS_ALG_CALLLOAD
+ && idx->dlist[i].attrs.maxload != 0
&& idx->dlist[i].dload >= idx->dlist[i].attrs.maxload) {
continue;
}
```
### Additional Information
I am using the following version. The issue appears to still exist in the master branch.
version: kamailio 5.3.2 (arm6/linux)
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, TLS_PTHREAD_MUTEX_SHARED
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: unknown
compiled on 17:22:09 Mar 18 2020 with gcc 8.3.0
Thank you.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2297
Thanks to the efforts made by Fred Posner, a matrix.org server has been
installed on Kamailio project infrastructure (matrix.kamailio.dev -
server sponsored by lod.com), which enables us to create chat rooms as
we need for our community of users and developers.
It tries to be an alternative to the existing IRC #kamailio channel,
given that a while ago freenode.net had to enforce user registration to
join the channels on their service (not complaining about it, they did
it for good reasons to protect against spammers and D/DoS attacks). The
#kamailio channel on freenode.net will still be in use by the people
that like it, there is no plan to consider it obsolete.
One of the main benefits of running own matrix server is the ability to
allow guest access during the devel online meetings, so people that do
not want to create an account can still participate by using a web
browser. Also, it offers modern encryption and privacy, along with
richer collaboration features (e.g., file sharing), many considering it
a viable open source alternative to Slack or other private team
collaboration services.
The first room created is #kamailio:matrix.kamailio.dev :
* https://riot.kamailio.dev/#/room/#kamailio:matrix.kamailio.dev
The matrix server is federated, so you can join if you have an account
on any other public federated matrix server or one that you can host
yourself. The server on matrix.kamailio.dev is not allowing public
registrations. If you are a registered developer (have git commit
access) and need a matrix account, let us know and we will find solutions.
It is the first phase now and based on the interest from the community,
its usage can be increased (e.g., creating rooms for development
notifications (commits, pull requests, issue); bridge to irc channel;
etc...) or the server can be shut down if proves not useful.
We will try to do the next online devel meeting (scheduled for
Wednesday, April 29, 2020, at 14:00UTC) on the matrix chat room
mentioned above.
More details at:
* https://www.kamailio.org/w/2020/04/matrix-chat-room-for-kamailio/
Stay safe and healthy!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda