[asterisk-dev] Violent Objections? CDR dst/dcontext probs in 1.4+ when a macro is involved.

[Steve Murphy]

On Thu, 2007-07-05 at 18:39 -0500, Tilghman Lesher wrote:
> On Thursday 05 July 2007 16:31, Steve Murphy wrote:
> > On Tue, 2007-07-03 at 16:38 -0500, Tilghman Lesher wrote:
> > > The core is adequate at this point.  What needs to happen is for
> > > the backends (finally) to take advantage of the CDR core features
> > > that have been there since 1.2 was released.
> >
> > which core CDR features are you referring to here?
> 
> Arbitrary CDR variables.  Until cdr_custom and cdr_adaptive_odbc,
> they have been completely unused, unless you built your own cdr backend
> (as I have done in the past).
> 

Ahhhhhh. OK, I tend to agree. I want to make (in future releases), CDR's
fairly simple, well documented, easy to implement, deathly accurate,
highly configurable, blah, blah. So, let's deprecate cdr_csv; upgrade
cdr_custom to the same coolness as adaptive_odbc; make cdr_custom
replace cdr_csv; look at any other stuff that might not have odbc
interfaces available.

Also, I've gotten some solid suggestions about the CDR backends, by a
user who was concerned that the current CDR backends just tossed a CDR
if they couldn't be logged.... he wants to make them more reliable. By
moving the batching facility from asterisk, into the backends, I figure
we could improve reliability.

This involves modifying the architecture of the backends a bit:

1. The backend now accepts a CDR from Asterisk, as it does now, but it
queues it
instead of immediately processing it. If the number of CDR's in the
queue get above a threshold, warnings can be issued. And, when it's time
to unregister the CDR, any remaining CDR's in the queue can be logged to
a file or whatever.
It will probably be wise for this part to send a signal alerting the
unqueueing end to the presence of a CDR.

2. When the backend is registered, a thread will be fired off that will
awake when there are elements in the queue to process. It will then pull
these CDR's out of the queue and post them. If there are difficulties,
it is up to this thread to post log messages, and handle the problem. If
a connection died, for instance, it might block until the connection
recovered. The object is to not lose CDR's when the problems may be
temporary.

3. Batching could still be achieved; the posting thread could wake up
when the number of CDRs in the queue reach a threshold.

4. The batching config specs could be moved from the general cdr config
file to the backend configs.

What do you think? Could this work better?

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070710/07f6797a/attachment.bin