[asterisk-dev] [Code Review] Rework CDR API Internals to Prevent Loss of CDR Records

Asterisk Development Team asteriskteam at digium.com
Thu Feb 25 08:36:19 CST 2010


Russell Bryant wrote:
> Summary
> -------
> 
> This code comes from the team/russell/cdr-q branch.  It is something I did on a couple of flights this week.
> 
> The current CDR implementation in Asterisk does nothing to ensure that every CDR record is successfully logged to configured logging destinations.  A single attempt is made to log a record.  If for some reason it fails, such as connectivity to a database being temporarily disrupted, then the records are lost.  Obviously, this is very bad in many cases where these records are used for things like billing.
> 
> The primary purpose behind these changes is to ensure that every record is successfully logged to every destination that has been configured.  If posting a CDR fails, it will be queued up for a retry later.
> 
> A new method has been added for backends to register callbacks for receiving CDR records.  For CDR modules that allow posting CDRs to multiple destinations, such as multiple DB tables or multiple text files, they now make a registration into the core for every destination.  That way, the success or failure of the attempt to each destination can be tracked.  All backends that need it have been updated to operate this way.
> 
> main/cdr.c has also been updated to use more modern Asterisk APIs.  It has also been updated with various other bits of code cleanup.
> 
> One side effect of these changes is that the code that previously implemented the batch mode has been completely removed, as that code is now deprecated.  The biggest benefit from batch mode was handling CDR posting asynchronously from channel threads.  In this code, that is the only behavior that exists.

This sounds very cool! Nice idea.

One thought I had when reading this was, "What happens if a backend is down for 
a considerable amount of time, such as, forever? Could this lead to memory being 
used up and eventually causing all memory to be used for storing queued up CDR 
records?"

If it could, perhaps there should be some sort of mechanism that an 
administrator can use to either monitor or control how much memory gets used for 
caching?

Leif.



More information about the asterisk-dev mailing list