asterisk users - Dec 2015 - CEL entries over ODBC several hours late (Vinicius Fontes)

Hi Vinicius

Thanks for replying.
>Sorry for the probably obvious question, but it's better to cover all
bases.
>The DBMS is running on the same box as Asterisk is? If that's the case
then
maybe the DBMS is using too much CPU and starving Asterisk?

I don't think so - I think I have a locking issue in the DB specifically
with my stored procedure -and- Asterisk trying to access the CEL table
simultaneously.

Load averages appear normal even if the DB is running in the background. The
autodestruct problem occurs whenever the CEL table (InnoDB, so should NOT be
locked for inserts while being queried in MySQL "nolock" equivalent,
but it
IS) is busy being read by the SP and Asterisk tries to write into it.

This then back-flows to the Asterisk and delays the H extension execution to
such a degree that handsets get locked tight until the CEL table lock held
by the SP is released and Asterisk can write to it again over ODBC.

I understand that CEL logging and call hangup should be an atomic operation
(billing related) from there though the question about why it apparently
(from observed effects) is a synchronous operation - but considering it must
be atomic, it does make sense I suppose to write CELs synchronously with
call teardown.

It just requires that you keep the CEL table in MariaDB (or whatever) in an
"un-locked" state at all times - which makes it pretty hard since to
have
any practical use out of the CEL table you should be able to query it
without locking it - which InnoDB in MariaDB is supposd to provide, but
clearly does not in my type of setup here.

Anyway, thanks for the reply.

Regards

Stefan

Since the issue seems to be table locking, why not take a shot with
PostgreSQL? It's way better and more robust than MySQL/MariaDB.

You should be able to create an additional DSN and output CEL to both
PostgreSQL and MariaDB.

2015-12-11 8:59 GMT-02:00 Stefan Viljoen <viljoens at verishare.co.za>:
> Hi Vinicius
>
> Thanks for replying.
>
> >Sorry for the probably obvious question, but it's better to cover
all
> bases.
>
> >The DBMS is running on the same box as Asterisk is? If that's the
case
> then
> maybe the DBMS is using too much CPU and starving Asterisk?
>
> I don't think so - I think I have a locking issue in the DB
specifically
> with my stored procedure -and- Asterisk trying to access the CEL table
> simultaneously.
>
> Load averages appear normal even if the DB is running in the background.
> The
> autodestruct problem occurs whenever the CEL table (InnoDB, so should NOT
> be
> locked for inserts while being queried in MySQL "nolock"
equivalent, but it
> IS) is busy being read by the SP and Asterisk tries to write into it.
>
> This then back-flows to the Asterisk and delays the H extension execution
> to
> such a degree that handsets get locked tight until the CEL table lock held
> by the SP is released and Asterisk can write to it again over ODBC.
>
> I understand that CEL logging and call hangup should be an atomic operation
> (billing related) from there though the question about why it apparently
> (from observed effects) is a synchronous operation - but considering it
> must
> be atomic, it does make sense I suppose to write CELs synchronously with
> call teardown.
>
> It just requires that you keep the CEL table in MariaDB (or whatever) in an
> "un-locked" state at all times - which makes it pretty hard since
to have
> any practical use out of the CEL table you should be able to query it
> without locking it - which InnoDB in MariaDB is supposd to provide, but
> clearly does not in my type of setup here.
>
> Anyway, thanks for the reply.
>
> Regards
>
> Stefan
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20151211/3e8039ac/attachment.html>