[asterisk-bugs] [JIRA] (ASTERISK-21228) Deadlock in pbx_find_extension when attempting an autoservice stop due to holding the context lock

[Dare Awktane (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205864#comment-205864 ] 

Dare Awktane edited comment on ASTERISK-21228 at 4/25/13 3:39 PM:
------------------------------------------------------------------

Yes - we have about 5500 switches in a realtime odbc version of the extensions.conf file. Sadly I have yet to see a way to tell asterisk that every context is in the database. We have to create a 1-3 contexts for every customer that we have to make sure that each customer only has access to their own extensions. An example of one of the entries is as follows:

| id     | cat_metric | var_metric | commented | filename        | category  | var_name | var_val    | stamp               |
| 248702 |          2 |        319 |         0 | extensions.conf | 310_319_0 | switch   | realtime/@ | 2013-04-19 02:26:26 |

Do you think it would help to look into another method of storing the extensions? I could try to make it so that a script took the entries in the database and output it to a hard extensions.conf file which could be reloaded each time we add a new context. As an alternative are you aware of a way to specify that all contexts or even a pattern match of contexts are stored in the realtime odbc version of extensions?
                
      was (Author: awktane):
    Yes - we have about 5500 switches in a realtime odbc version of the extensions.conf file. Sadly I have yet to see a way to tell asterisk that every context is in the database. We have to create a 1-3 contexts for every customer that we have to make sure that each customer only has access to their own extensions. An example of one of the entries is as follows:

+--------+------------+------------+-----------+-----------------+-----------+----------+------------+---------------------+
| id     | cat_metric | var_metric | commented | filename        | category  | var_name | var_val    | stamp               |
+--------+------------+------------+-----------+-----------------+-----------+----------+------------+---------------------+
| 248702 |          2 |        319 |         0 | extensions.conf | 310_319_0 | switch   | realtime/@ | 2013-04-19 02:26:26 |
+--------+------------+------------+-----------+-----------------+-----------+----------+------------+---------------------+

Do you think it would help to look into another method of storing the extensions? I could try to make it so that a script took the entries in the database and output it to a hard extensions.conf file which could be reloaded each time we add a new context. As an alternative are you aware of a way to specify that all contexts or even a pattern match of contexts are stored in the realtime odbc version of extensions?
                  
> Deadlock in pbx_find_extension when attempting an autoservice stop due to holding the context lock
> --------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21228
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21228
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/PBX
>    Affects Versions: 1.8.20.1, 1.8.21.0, 11.2.1, 11.3.0
>         Environment: Linux 3.2.0-38-generic #61-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Dare Awktane
>            Severity: Critical
>         Attachments: 1366481920-backtrace_threads.txt, 1366481920-core_show_locks.txt, 1366495718-backtrace_threads.txt, 1366495718-core_show_locks.txt, backtrace-threads.txt, core-show-locks.txt
>
>
> We have two asterisk machines running inbound/outbound/fax calls on both. We've developed a web application that people can use to create accounts (which flow through into asterisk as contexts). We have a cron script that calls -rx "dialplan reload" to update these contexts. Both the extconfig.conf and extensions.conf are loaded from a mysql clustered (ndb) database. Roughly 2-3 times a day each asterisk server stops taking calls and does not restart on its own. I'm not sure if all of the lockups are related to this dump. We braved a morning of bad call quality to have the debug flags set. Our dialplan shows that it has 494197 rows. A reasonably large dialplan.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira