presence: Fix database purge of activewatchers (clustering, fallback2db=0) #2520
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(This one might be for you @bogdan-iancu 😉 . See also PR #2519. Both affect both the 2.4.x and 3.1.x branches.) |
|
Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days. |
…ck2db)
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.)
wdoekes
force-pushed
the
fix-database-purging-of-activewatchers-with-no-fallback2db
branch
from
5120dac
to
b01bb18
Compare
|
Rebased, just in case |
|
Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days. |
|
Marking as closed due to lack of progress for more than 30 days. If this issue is still relevant, please re-open it with additional details. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
The non-OK behaviour above refers to the activewatcher table getting filled up with stale/expired items.
fallback2db on or off:
The no-clustering case:
The tagless case:
The active case:
Where PR #2519 fixes the tagless case, this PR fixes the
fallback2db=0case 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.)