[asterisk-dev] sqlite concurrency - queue_log/cel

marek cervenka cervajs2 at gmail.com
Thu May 25 17:28:51 CDT 2017


great. patch is on gerrit

btw what do you think about WAL mode for asterisk internal sqlite astdb?


Dne 22/05/2017 v 22:59 Matt Fredrickson napsal(a):
> On Mon, May 22, 2017 at 10:06 AM, marek cervenka <cervajs2 at gmail.com> wrote:
>> hi,
>>
>> first of all, i know sqlite is not designed for concurrency
>>
>> workarounds are wal - https://www.sqlite.org/wal.html . can be specified
>> when creating DB with "pragma journal_mode=wal"
>>
>> and
>>
>> busy_timeout https://www.sqlite.org/c3ref/busy_timeout.html . MUST be
>> specified per connection
>>
>>
>> we are using sqlite for cel and queue_log.
>>
>> https://github.com/asterisk/asterisk/blob/master/res/res_config_sqlite3.c
>>
>> https://github.com/asterisk/asterisk/blob/master/cel/cel_sqlite3_custom.c
>>
>> busy_timeout is hardcoded (value is in ms)
>>
>> sqlite3_busy_timeout(db->handle, 1000);
>>
>>
>> will you accept patch where busy_timeout will be configurable?
>>
>>
>> btw our use case is
>>
>> - central data warehouse
>>
>> - apache kafka as receiver
>>
>> - every asterisk has producer (node.js) which analyze sqlite cel/queue_log.
>> producer builds call structure and send it to kafka.  main problem is in
>> updating sqlite cel/queue_log by producer which rows was sent (concurrent
>> write access)
> I don't specifically have a problem with making busy_timeout
> configurable, as long as it has the same default value as it is now.
>
> That's just one guy's opinion though :-)
>
> ---
> Matthew Fredrickson
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>




More information about the asterisk-dev mailing list