We are running Kamailio 5.1.x in a mixed native/Kemi environment. That means, most of the config is still native Kamailio language, but some newer functions were written in JS and included via jsdt_run("...");
.
In one of those functions, we place an sqlops query. And since introducing this code, Kamailio leaks memory. Slowly, but eventually, the private memory will fill up.
In Kamailio, the code looks like this:
if (!jsdt_run("ksrIsCallAccountingRequired", "$(var(accentries){s.select,10,|})", "$(var(accentries){s.select,12,|})")) {
xlog("L_ERR", "JS Call of ksrIsCallAccountingRequired route failed.\n");
}
And our JS code containing sqlops looks like this:
extension = '1234567e0';
mastersipid = '1234567';
KSR.sqlops.sql_query(
"dbconn",
`SELECT username, grp FROM grp WHERE username IN ('${mastersipid}', '${extension}') AND grp = 'ourGroupName'`,
user
);
For each call, this query is executed once. Depending on the traffic, you can see the private package memory starting to fill up quicker or slower.
We had a similar problem about two years ago with app_lua and getting entries from a hash table, which we solved by introducing a temporary variable for using in the hash table index instead of strings. We tried doing the same thing in our current setup:
KSR.pv.sets("$var(extensionForQuery)", extension);
KSR.pv.sets("$var(masterSipidForQuery)", masterSipid);
KSR.sqlops.sql_query(
"dbconn",
"SELECT username, grp FROM grp WHERE username IN ('$var(masterSipidForQuery)', '$var(extensionForQuery)') AND grp = 'ourGroupName'",
user
);
However, Kamailio doesn't replace the variables in the query string. Although the documentation of the sqlops module says, it supports pseudovars in the query string. We even tried putting the whole query into a variable, but ended up with a sqlops error.
ersion: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 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 with gcc 4.7.2
Debian Wheezy (yeah, I know... )
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.