[asterisk-bugs] [JIRA] (ASTERISK-28857) #exec call in pjsip.conf causes large delay (60 seconds) when reloading pjsip, partially locks up dialplan.

[Steve Sether (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Sether updated ASTERISK-28857:
------------------------------------

    Description: 
We use a #exec statement at the end of our pjsip.conf file to generate sip peers.  The list is somewhat long, and takes about 4 seconds to generate.

When I use a #exec in the pjsip.conf to generate my sip peers, and do a pjsip reload, Asterisk will stop processing certain commands (The dial function for instance), the console shows no progress,  and Asterisk takes a full 60 seconds to reload pjsip.  When I generate the same contents statically, and do a pjsip reload, it reloads in under a second, and doesn't lock anything up.

This is fairly easy to reproduce, and has something to do with the script executing taking a few seconds to complete.  If I simulate a 4 second pause that my script takes to generate sip peers, I can reproduce this behavior. 

#!/bin/sh
cat /root/pjsip_peers_part.conf
sleep 4

I get essentially the same results where pjsip locks up.  The length of /root/sippers.conf can be trivially short.  Example config files attached.

This was not an issue for the #execute command in sip.conf in Asterisk 11.

  was:
We use a #exec statement at the end of our pjsip.conf file to generate sip peers.  The list is somewhat long, and takes about 4 seconds to generate.

When I use a #exec in the pjsip.conf to generate my sip peers, and do a pjsip reload, Asterisk will stop processing certain commands (The dial function for instance), the console shows no progress,  and Asterisk takes a full 60 seconds to reload pjsip.  When I generate the same contents statically, and do a pjsip reload, it reloads in under a second, and doesn't lock anything up.

This is fairly easy to reproduce, and has something to do with the script executing taking a few seconds to complete.  If I simulate a 4 second pause that my script takes to generate sip peers, I can reproduce this behavior. 

#!/bin/sh
cat /root/pjsip_peers_part.conf
sleep 4

I get essentially the same results where pjsip locks up.  The length of /root/sippers.conf can be trivially short.  Example config files attached.


> #exec call in pjsip.conf causes large delay (60 seconds) when reloading pjsip, partially locks up dialplan.
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28857
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28857
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip
>    Affects Versions: 16.9.0
>         Environment: Centos 6.9.
>            Reporter: Steve Sether
>         Attachments: generate.sh, pjsip.conf, pjsip_peers_part.conf
>
>
> We use a #exec statement at the end of our pjsip.conf file to generate sip peers.  The list is somewhat long, and takes about 4 seconds to generate.
> When I use a #exec in the pjsip.conf to generate my sip peers, and do a pjsip reload, Asterisk will stop processing certain commands (The dial function for instance), the console shows no progress,  and Asterisk takes a full 60 seconds to reload pjsip.  When I generate the same contents statically, and do a pjsip reload, it reloads in under a second, and doesn't lock anything up.
> This is fairly easy to reproduce, and has something to do with the script executing taking a few seconds to complete.  If I simulate a 4 second pause that my script takes to generate sip peers, I can reproduce this behavior. 
> #!/bin/sh
> cat /root/pjsip_peers_part.conf
> sleep 4
> I get essentially the same results where pjsip locks up.  The length of /root/sippers.conf can be trivially short.  Example config files attached.
> This was not an issue for the #execute command in sip.conf in Asterisk 11.



--
This message was sent by Atlassian JIRA
(v6.2#6252)