| Summary: | ASTERISK-28247: res_ari: Applications not being cleaned up after certain scenarios | ||
| Reporter: | Benjamin Keith Ford (bford) | Labels: | |
| Date Opened: | 2019-01-16 10:22:36.000-0600 | Date Closed: | |
| Priority: | Minor | Regression? | No |
| Status: | Open/New | Components: | Resources/res_ari |
| Versions: | 13.24.1 16.1.1 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) example-app | |
| Description: | When working on the 'move' REST API call, I noticed that there were certain situations where the app_dtor function was not called, since I was using this to remove automatically created contexts and extensions for Stasis applications when launched. The pattern seems to be when an application is shutdown from the terminal and the phones are hung up after that, the application lingers and is not destroyed. There's a series of 3 functions that are called - deactivate, shutdown, and destroy. When this happens, you can see the first 2 phases being executed, but not the third (verbose 1).
The way I've replicated this is by having a Stasis application that finds a mixing bridge or creates one if not already present, and puts all channels into the bridge. Once you have 2 channels in the bridge, close the application (Ctrl+C) from the terminal. After that, hang up the channels. List the ARI applications on the CLI afterwards, and you can see that the application is still listed. | ||
| Comments: | |||