[asterisk-bugs] [Asterisk 0012766]: Failure of resetting of a PRI B-Channel causes deadlock in process

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12766 
====================================================================== 
Reported By:                mavetju
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12766
Category:                   Channels/chan_zap
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-31-2008 01:31 CDT
Last Modified:              06-17-2008 19:40 CDT
====================================================================== 
Summary:                    Failure of resetting of a PRI B-Channel causes
deadlock in process
Description: 
By default, once every hour, the Asterisk system resets the channels of a
PRI. This workflow is based on "reset the first channel"; when the reset
gets acknowledged "let's reset the next channel" until all channels are
done. This works fine if all channels get acknowledged, but when an
acknowledgment isn't received, the whole system is deadlocked for that
PRI.

====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 06-17-08 19:40  
---------------------------------------------------------------------- 
I need a couple of changes before this can go in:

1) In the first hunk of the patch, the comment on resettimeout is exactly
the same as on resetinterval.  This needs to be changed to distinguish the
two values.

2) You're using time() to get when the reset started.  Due to timing, that
means that a value of 3 for the resettimeout could wait as little as 2.001
seconds before the timeout will fire, rather than a full 3 seconds.  I'd
prefer if you switched this to using 'struct timeval' and ast_tvnow() (with
ast_tvdiff_ms() to calculate the difference).

3) Instead of calling it 'recover from deadlock', I'd like to see
something more along the lines of 'provider did not acknowledge reset --
channel may not get used'. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-17-08 19:40  Corydon76      Note Added: 0088850                          
======================================================================