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

[Steve Murphy]

On Tue, 2007-07-10 at 12:37 -0500, Tilghman Lesher wrote:
> 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.

You've grouped two things in (2), with a common assumption that one will
immediately, or at least inevitably, lead to the second-- a system
error 
like full disk, or a temporarily dropped connection to a db server need
not always lead to catastrophic failure of asterisk. 

It might be nice if an upper threshold could also be set, where if the
number of backed up CDR's got above that value, then the backend would
log some errors and dump the CDR's to a text file. Some poor schmoe
could pick up the pieces later and somehow get them back into the db
somehow. Maybe we could dump them in SQL insert command format or
something to make it easy. If disk is full, well, that's that. Not much
that can be done. Maybe allow the user to set the
name of the file we would append such data to; hopefully on a different
disk or something!

Transient db conditions, like a dropped or timed out connection? seems
like I've seen email mentioning this sort of scenario over the past
number of months in asterisk-users, -dev, or wherever...

Pie-in-the-sky: what if we caught segfaults and "tried" to traverse the
backends and push the CDRs out before the final curtain?

We could also log warnings to console and even resort to generating
email to admins, if disk gets up over 90% or more full, stuff like that,
also...

murf





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070710/d8b77a12/attachment-0001.bin