[asterisk-dev] [Code Review] 2880: CDRs: prevent backend modules from unregistering while active CDRs are in flight

[Corey Farrell]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2880/#review9823
-----------------------------------------------------------



/branches/12/main/cdr.c
<https://reviewboard.asterisk.org/r/2880/#comment19028>

    Any call to ast_cdr_unregister done from a config reload needs to succeed - cdr_manager, cdr_odbc, cdr_mysql do this.  For disabled modules ast_cdr_unregister / module_unload should not be blocked.
    
    Returning an int instead of void doesn't cause build warnings or errors for existing unmodified cdr modules.  Any such module would crash on cli module unload with active_count != 0.
    
    A parameter could be added to force ast_cdr_unregister.  The other idea I have is expose a function to retreive active_count, leave it up to each module unload to decide if it should continue.


- Corey Farrell


On Sept. 25, 2013, 12:07 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2880/
> -----------------------------------------------------------
> 
> (Updated Sept. 25, 2013, 12:07 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> During shutdown, Asterisk attempts to flush out any active CDRs by calling ast_cdr_engine_term. This is to try to get as much billing data recorded as possible before Asterisk shuts down/restarts and that data is lost. Unfortunately, module unloading occurs prior to calling ast_cdr_engine_term, and the CDR backend modules have already unregistered themselves. Thus, while the records are successfully flushed from the system, there are no registered backends left to handle the data.
> 
> This is technically a problem in prior versions of Asterisk as well; however, it is far less likely to occur in Asterisk 1.8/11 due to CDRs being build on an asynchronous message bus in Asterisk 12.
> 
> This patch modified ast_cdr_unregister such that if active_cdrs_by_channel has an entry, the unregistration fails. This would have the side effect of preventing CDR module unloading via the CLI on a busy system - but if you're doing that, you're already losing billing data, so that seems like a very bad idea anyway.
> 
> 
> Diffs
> -----
> 
>   /branches/12/main/cdr.c 399775 
>   /branches/12/include/asterisk/cdr.h 399775 
>   /branches/12/cdr/cdr_tds.c 399775 
>   /branches/12/cdr/cdr_syslog.c 399775 
>   /branches/12/cdr/cdr_sqlite3_custom.c 399775 
>   /branches/12/cdr/cdr_sqlite.c 399775 
>   /branches/12/cdr/cdr_pgsql.c 399775 
>   /branches/12/cdr/cdr_radius.c 399775 
>   /branches/12/cdr/cdr_odbc.c 399775 
>   /branches/12/cdr/cdr_manager.c 399775 
>   /branches/12/cdr/cdr_custom.c 399775 
>   /branches/12/cdr/cdr_csv.c 399775 
>   /branches/12/cdr/cdr_adaptive_odbc.c 399775 
> 
> Diff: https://reviewboard.asterisk.org/r/2880/diff/
> 
> 
> Testing
> -------
> 
> The various dial tests that have a tendency to end very quickly while CDR data is in flight now pass consistently.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130927/2ff4d063/attachment-0002.html>