Skip to content

Commit b01bb18

Browse files
committedJul 26, 2021
presence: Fix database purge of activewatchers (clustering, no fallback2db)
When clustering sharing_tags were added to presence, they were added to the fallback2db "on" case only: There are a couple of dimensions with differing behaviours: +------------+------------+ | fallback2- | fallback2- | | -db = on | -db = off | +-clustering:-+------------+------------+ | - no | OK | OK | | - tagless | PR-2519 | PR-2519 | | - active | OK | this | +-------------+------------+------------+ The non-OK behaviour above refers to the activewatcher table getting filled up with stale/expired items. fallback2db on or off: ``` modparam("presence", "fallback2db", 0) # or 1=on ``` The no-clustering case: ``` handle_subscribe(); ``` The tagless case: ``` modparam("presence", "cluster_id", 1) modparam("clusterer", "my_node_id", 2) handle_subscribe(); ``` The active case: ``` modparam("presence", "cluster_id", 1) modparam("clusterer", "my_node_id", 2) modparam("clusterer", "sharing_tag", "node2/1=active") handle_subscribe("0", "node2"); ``` Where PR OpenSIPS#2519 fixes the tagless case, this PR fixes the fallback2db=0 case by writing the sharing_tag to the database so the records can get found and cleaned up. (Sidenote: subscriptions which ended with a timeout or 481 *would* get cleaned up. This makes sense in all cases: if they have an error before their expiry, it makes sense to purge them from the DB immediately. And if the periodic cleanup had cleaned those records already, it would not be an issue.)

File tree

1 file changed

+18
-6
lines changed

1 file changed

+18
-6
lines changed
 

‎modules/presence/subscribe.c

+18-6
Original file line numberDiff line numberDiff line change
@@ -1363,9 +1363,10 @@ void update_db_subs(db_con_t *db,db_func_t *dbf, shtable_t hash_table,
13631363
db_op_t update_ops[2];
13641364
subs_t* del_s;
13651365
int pres_uri_col, to_user_col, to_domain_col, from_user_col, from_domain_col,
1366-
callid_col, totag_col, fromtag_col, event_col,status_col, event_id_col,
1366+
callid_col, totag_col, fromtag_col, event_col, status_col, event_id_col,
13671367
local_cseq_col, remote_cseq_col, expires_col, record_route_col,
1368-
contact_col, local_contact_col, version_col,socket_info_col,reason_col;
1368+
contact_col, local_contact_col, version_col, socket_info_col,
1369+
sharing_tag_col, reason_col;
13691370
int u_expires_col, u_local_cseq_col, u_remote_cseq_col, u_version_col,
13701371
u_reason_col, u_status_col, u_contact_col;
13711372
int i;
@@ -1471,14 +1472,19 @@ void update_db_subs(db_con_t *db,db_func_t *dbf, shtable_t hash_table,
14711472
query_vals[local_contact_col].nul = 0;
14721473
n_query_cols++;
14731474

1475+
query_cols[version_col= n_query_cols]=&str_version_col;
1476+
query_vals[version_col].type = DB_INT;
1477+
query_vals[version_col].nul = 0;
1478+
n_query_cols++;
1479+
14741480
query_cols[socket_info_col= n_query_cols] =&str_socket_info_col;
14751481
query_vals[socket_info_col].type = DB_STR;
14761482
query_vals[socket_info_col].nul = 0;
14771483
n_query_cols++;
14781484

1479-
query_cols[version_col= n_query_cols]=&str_version_col;
1480-
query_vals[version_col].type = DB_INT;
1481-
query_vals[version_col].nul = 0;
1485+
query_cols[sharing_tag_col= n_query_cols] =&str_sharing_tag_col;
1486+
query_vals[sharing_tag_col].type = DB_STR;
1487+
query_vals[sharing_tag_col].nul = 0;
14821488
n_query_cols++;
14831489

14841490
/* cols and values used for update */
@@ -1643,10 +1649,16 @@ void update_db_subs(db_con_t *db,db_func_t *dbf, shtable_t hash_table,
16431649
query_vals[socket_info_col].val.str_val.s = 0;
16441650
query_vals[socket_info_col].val.str_val.len = 0;
16451651
}
1652+
if (s->sh_tag.len == 0) {
1653+
query_vals[sharing_tag_col].nul = 1;
1654+
} else {
1655+
query_vals[sharing_tag_col].nul = 0;
1656+
query_vals[sharing_tag_col].val.str_val = s->sh_tag;
1657+
}
16461658

16471659
CON_SET_CURR_PS(db, &my_ps_insert);
16481660
if (dbf->insert( db, query_cols, query_vals,
1649-
n_query_cols) < 0)
1661+
n_query_cols) < 0)
16501662
{
16511663
LM_ERR("unsuccessful sql insert\n");
16521664
}

0 commit comments

Comments
 (0)
Please sign in to comment.