#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail --> due to the way update_db_subs_timer_dbonly handles the query to the database (getting all records), if for some reason a burst of terminating subscriptions occurs, most likely there will be no package memory to process all expiring subscriptions.
this commit uses the same pattern as other routines in presence by using db_fetch_query with fetch_rows parameter module.
because we create the subs in the loop and then call handle_expired_subs to avoid locking issues the subscription should already be deleted from the database when it returns from handle_expired_subs, there's no reason to issue the last delete, and that was removed. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1609
-- Commit Summary --
* presence: limit the number of subscriptions handled in timer_dbonly
-- File Changes --
M src/modules/presence/subscribe.c (41)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1609.patch https://github.com/kamailio/kamailio/pull/1609.diff
If the removal of the delete at the end was tested properly without side effects, I am fine to merge.
@miconda yes it was, the callback of the notify deletes the subscription. it actually is required because in the case where we have `fetch_rows=500` and the entire result set is `5000` rows then we would loose `4500` rows because they would be deleted.
this is causing problems in some `production` servers and i would like to backport to stable branches if that's ok
Ok to backport.
Merged #1609.