[asterisk-bugs] [Zaptel 0012405]: [patch] bad master selection (2 different ways)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12405 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   12405
Category:                   zaptel (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Zaptel Version:             1.4.9.2 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-10-2008 05:44 CDT
Last Modified:              04-11-2008 16:37 CDT
====================================================================== 
Summary:                    [patch] bad master selection (2 different ways)
Description: 
Current zaptel master handling work in the following way:
The first SPAN become a master
If a new registered !!! SPAN is preferred , it is the new master
If a span is unregistered - the new master is the first available span
If master SPAN is in alarm state - the new master is the first non in
alarm state SPAN

So
1. ztdummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...

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

---------------------------------------------------------------------- 
 tzafrir - 04-11-08 16:37  
---------------------------------------------------------------------- 
Why not shoot higher, and make the extra parameter to zt_register the
span's priority?

There's a FIXME note you remove about locking. What do you do about this?
You reverted an old change to keep the newly-selected master in a
temporary variable new_master and left master set to NULL for a while.

check_master is callable from modules. What exactly do you assume about
locking when that route is used?


BTW (2): you seem to submit patches vs a released version. If you use
diff, you can get slightly prettier diffs with the option -p
(--show-c-function) to diff. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
04-11-08 16:37  tzafrir        Note Added: 0085383                          
======================================================================