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

[Tilghman Lesher]

On Tuesday 10 July 2007 11:14, Steve Murphy wrote:
> 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.

Well, kind of.  I think the batching code needs to remain in cdr.c, to
reduce duplication of code, but the batching could be made better, in
terms of creating a queue per backend.  Right now, if a single backend
fails to log a CDR, that backend simply doesn't get the record, batching 
or no.

The problem still remains, if a CDR backend failed to record a CDR, it
could be for several different reasons:
  1) a bug in the backend.  In this case, retrying won't make a
difference, and queuing would be bad, given that the records are simply
going to eat memory until Asterisk crashes and the records would be
lost anyway.
  2) a system error, such as a full disk, which needs the attention of
an administrator.  Again, if not tended to within a short period of
time, this will cause memory to be eaten until Asterisk crashes and the
records will be lost anyway.  In this case, logging to a file would
likely fail, if the database and Asterisk are on the same machine (which
is fairly typical).
  3) a transient database condition, such as high database load.  In
this case, there is a possibility that recovery will occur in time to
avoid a crash and the loss of CDRs.

In the time I've been administering Asterisk, I have seen conditions 1
and 2 a few times.  I have never seen condition 3, although this is the
problem you're attempting to solve.  I'd like to know how many times
people have seen condition 3, because if it never happens, then we're
coding a useless solution.

-- 
Tilghman