[asterisk-dev] 1.4 and CDRs -- The Breaking Point

[Venefax]

I think that only the Freetds engineers, who also know the Asterisk code,
may clear the point. I am copying Frediano Ziglio and also the Freetds List.


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tilghman Lesher
Sent: Sunday, February 08, 2009 1:27 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] 1.4 and CDRs -- The Breaking Point

On Saturday 07 February 2009 14:25:30 Venefax wrote:
> I did not test it. I don't think that the driver has anything to do with
> this. If you read carefully what has been written you may achieve the same
> conclusion.
> a) Freetds allows me to execute 100+ simultaneous queries to the database,
> on separate channels. Open Connection, Execute, Close Connection.
> b) Asterisk slows down to a halt in the same scenario. The difference is
> that the connections are never closed, are "pooled".

If you believe that reconnecting for every single query would make a
difference, that is a very easy change.  However, given the single-engine-
multi-instance aspect, I doubt this will have a positive effect.  But I'd be
happy to code it, if you're willing to test it.

> If you compare a) to b), there is no way to blame the driver. This
> absolutely absurd. The driver opens a connection and keeps a list of open
> connections in its internal structure. It is a black box. This black box
> does in fact work as expected, because at the same second I may have
dozens
> of independent queries being processed using Perl.

I think you're revealing a fundamental lack of understanding about the
codebase.  The only way that I could see a relevant comparison is if your
Perl
process was multi-threaded, running Fast AGI, and running multiple queries
without ever shutting down.  As it stands, I believe that you're running
multiple Perl instances, which means that you aren't testing FreeTDS for
concurrent queries, the way Asterisk runs.  As a result, your determination
that the driver is not at fault is sorely lacking.

> I think that a portion of the sharing mechanism inside Asterisk's ODBC
> technology is keeping a lock longer than necessary.

You're free to think whatever you like; the difference here is that the
entire
codebase is open source, so all are welcome to look and determine for
themselves if any part is holding any lock for longer than necessary.  I've
reviewed the codebase multiple times, and I've found nothing to backup such
a
claim.

-- 
Tilghman

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev