CEL Entries Over ODBC Several Hours Late (Vinicius Fontes)
Hi Vinicius
Thanks for replying.
bases.
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
One thought on - CEL Entries Over ODBC Several Hours Late (Vinicius Fontes)
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: