|Summary:||ASTERISK-15824: Create CDR queue so records are not lost when connectivity is lost|
|Reporter:||Leif Madsen (lmadsen)||Labels:|
|Date Opened:||2010-03-16 13:12:49||Date Closed:||2013-05-16 10:50:15|
|Description:||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.
****** STEPS TO REPRODUCE ******
I have done some manual testing. However, before I consider this done, I would like to implement some automated tests, as well as touch on more backends than what I have tested so far.
I configured cdr_custom to log CDRs to multiple files. I made calls and verified that records were logged successfully. I made some modifications on disk such that attempts to log to one file would fail, while the other would continue to succeed. I made more calls and verified that the CDR queue grew for the specific file that had failures. I fixed the problem and continued making calls. I verified that all previously failed CDRs were posted and that both files were in sync with the number of CDRs that they had.
****** ADDITIONAL INFORMATION ******
Branch available at: http://svn.asterisk.org/svn/asterisk/team/russell/cdr-q/
|Comments:||By: Leif Madsen (lmadsen) 2010-03-16 13:13:18|
Marked as Confirmed until russell deems this ready for testing.
By: Leif Madsen (lmadsen) 2010-03-16 13:21:10
Is this ready for testing?
By: Russell Bryant (russell) 2010-07-10 09:33:36
No, it's not ready for testing. There rae some problems with reload that I need to resolve.
By: Juan P. Daza P. (tcpip4000) 2013-05-16 10:31:19.608-0500
Any new message about this issue?, I'm working on asterisk 188.8.131.52 and the problem persist maybe should I try 10?
Thanks for your help.
By: Matt Jordan (mjordan) 2013-05-16 10:50:06.156-0500
Hm. I had no idea this was still open.
No effort has been done on this particular new feature idea since 2010, i.e., no version of Asterisk contains this feature. Since new features only go into trunk, the earliest version that would support such a feature is Asterisk 12.
While CDRs are being given a lot of attention in Asterisk 12, it is only because of the work going on in the bridging framework. At this time, there is no plan to add or address this new feature, and, given the limited time remaining before Asterisk 12 is branched and new features are frozen, it will not be added to that work.
New features are actually not kept open in the Issue tracker unless they are being actively worked or there is a patch available and attached to the issue. In this case, none of those things are true - so I'm actually going to close this out as "Suspended" so that it doesn't cause any further confusion.