-
Notifications
You must be signed in to change notification settings - Fork 577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Possible dialog memory leak on combination $DLG_timeout $DLG_delay_delete #3370
Comments
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. |
in progress |
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. |
In progress |
Do you have a minimal working cfg reproducing the issue (like how to combine the 2 options in the way that the dialogs get stuck in state 5) ? |
Hello Bogdan,
|
And how does the call terminate? via timeout ? or via BYE ? |
Normally completed with BYE. |
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. |
In progress |
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. |
in progress |
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. |
In progress |
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. |
Hi, We're seeing the same behaviour in an active / passive cluster (version 3.4.8) with active/backup sharing tags (no DB) and have narrowed the cause down to one scenario (in our case). It seems that dialogs that are CANCELED with a response of 487 (no BYE) before answer hang around on the active server until restart - they're shown in the output of dlg_list on the active server. These dialogs replicate correctly to the passive node and correctly disappear from the output of dlg_list on the passive node. The odd part in the output of dlg_list on the active node seems to be that they all have the following in common:
No timestart and no timeout. Restarting the active node clears the dialogs and syncs active dialogs from the passive node correctly. EDIT: In our case there is no delete delay set and adding one makes no difference to the behaviour. Luis |
Version
Issue
In combination of vars $DLG_del_delay and $DLG_timeout causing dialogs with state 5 never be removed, which causing out of memory issues.
Specific vm is 8GB share memory and 12 Gb physical ( not over provisioned)
Share Memory stats for 24 h
Code
SHM dump
opensips-SHM-dump.txt
The text was updated successfully, but these errors were encountered: