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

[Matt Jordan]

> On Oct. 7, 2013, 12:28 p.m., Corey Farrell wrote:
> > /branches/12/main/cdr.c, lines 2592-2596
> > <https://reviewboard.asterisk.org/r/2880/diff/4/?file=47008#file47008line2592>
> >
> >     Sorry didn't notice this one before, if the backend is already suspended then aren't we successful?  It seems only an unregistered backend should cause an error return.

I was being a bit more strict, that is, suspending an already suspended backend is an error (as is unsuspending an already unsuspended backend). That being said, I don't think that adds any value and I like your suggestion better, so I'll go ahead and make this more tolerant to multiple suspend/unsuspend requests.


> On Oct. 7, 2013, 12:28 p.m., Corey Farrell wrote:
> > /branches/12/main/cdr.c, line 2663
> > <https://reviewboard.asterisk.org/r/2880/diff/4/?file=47008#file47008line2663>
> >
> >     if (!active_count || i->suspended) {
> >       AST_RWLIST_REMOVE_CURRENT(list);
> >     }
> >     
> >     I think active_count init should happen above the loop as it was in a previous diff, and that failure return should stay after the loop.

I don't think the location of active_count makes a big difference here, although I don't mind moving it earlier. The real problem is the act of removing the backend from the list prior to determining whether or not we can safely unregister. Fixed that.


- Matt


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


On Oct. 4, 2013, 9:59 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2880/
> -----------------------------------------------------------
> 
> (Updated Oct. 4, 2013, 9:59 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/addons/cdr_mysql.c 400553 
>   /branches/12/cdr/cdr_adaptive_odbc.c 400553 
>   /branches/12/cdr/cdr_csv.c 400553 
>   /branches/12/cdr/cdr_custom.c 400553 
>   /branches/12/cdr/cdr_manager.c 400553 
>   /branches/12/cdr/cdr_odbc.c 400553 
>   /branches/12/cdr/cdr_pgsql.c 400553 
>   /branches/12/cdr/cdr_radius.c 400553 
>   /branches/12/cdr/cdr_sqlite.c 400553 
>   /branches/12/cdr/cdr_sqlite3_custom.c 400553 
>   /branches/12/cdr/cdr_syslog.c 400553 
>   /branches/12/cdr/cdr_tds.c 400553 
>   /branches/12/include/asterisk/cdr.h 400553 
>   /branches/12/main/cdr.c 400553 
> 
> 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/20131014/b20c5ccb/attachment.html>