Open danieludy opened 3 years ago
On the latter point, there may be a slow memory leak of some kind where a sip dialog is not being freed by drachtio in certain situations. I am trying to track these down and fix them as they are identified. If you are able to identify specific call scenarios where the drachtio_stable_dialogs value does not decrement after the call is complete, please do open an issue on that.
On the first question, drachtio_stable_dialogs represents dialogs in progress (active), I am actually not sure if drachtio_sofia_dialogs (which is reported by the sofia stack) is meant to be cumulative or active. I will have a look.
Is there any way to dump the active dialogs within sofia to be able to see which ones are leaking? Finding which of the 1338138 calls resulted in the 1300 "leaked" dialogs would be a little hard unless there was an obvious error message to look for.
yes if you send a SIGHUP signal to the drachtio process the next time it writes stats to the log file (every 30 secs) it will include voluminous detail on the dialogs that are active
Thanks Dave the above worked... Now trying to go through a dialog that was stuck vs one that wasn't to find the difference... To try and speed things along can you tell me where the sofia dialog is added/removed? This is a B2BUA call if it makes a difference and appears to be the B leg.
In most cases, the sofia "leg" (analagous to the SipDialog at the drachtio application level), should get destroyed in the SipDialog destructor:
when the call hangs up
We have something that we can't explain. First here is the output from prometheus:
Our question is how/why are the drachtio_sofia_dialogs and drachtio_stable_dialogs counts so different? I would have assumed that a sofia dialog should correlate to a drachtio dialog. Is there something I am missing here? Side note, we noticed this because the drachtio_sofia_dialogs seemed to be slowly leaking over time. It would go up and down with load but the baseline would steadily increase.