arnaudcoquelet / fusionpbx

Automatically exported from code.google.com/p/fusionpbx
0 stars 0 forks source link

Sqlite database locked during voicemail operations. #814

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Leave yourself a voice message.
2.Place some calls to simulate load.
3.During simulated load call voicemail and delete the message.

What is the expected output? What do you see instead?

Message should be deleted from disk and database.
It is deleted from disk but not from sqlite database.
There is error message in the log file:
2014-12-01 12:59:34.621098 [ERR] switch_core_sqldb.c:586 NATIVE SQL ERR 
[database is locked]
DELETE FROM v_voicemail_messages
                WHERE domain_uuid = 'a63eca1d-d6a7-446c-b98c-243fbf412522'
                AND voicemail_uuid = '2a2158ab-f8cf-4990-b900-2a938d8ef63a'
                AND voicemail_message_uuid = 'fbdf1ee8-7981-11e4-9cf0-e534494d3841'
2014-12-01 12:59:34.621098 [ERR] freeswitch_lua.cpp:446 DBH NOT Connected. 

All voicemail operations are affected (INSERT, UPDATE, DELETE)

What version of the product are you using? On what operating system?

Multiple fresh scripted installs on Ubuntu 12 and Debian 7.8 
Latest freeswitch and fusionpbx versions with Sqlite3 database.
System CPU load is 5% max.

Error is very consistent and happens every day on system with 30 extensions and 
few simultaneous calls.

Original issue reported on code.google.com by Sergey.M...@gmail.com on 16 Jan 2015 at 5:19

Attachments:

GoogleCodeExporter commented 9 years ago
You should move to PGSQL, SQLite databases can lock up quickly. Depending on 
disk speed, etc. You can also try moving the SQLite db to ramdisk.

Original comment by nysoluti...@gmail.com on 16 Jan 2015 at 5:23

GoogleCodeExporter commented 9 years ago
nysolutions suggestions are correct SQLite is not built for concurrency. SQLite 
is recommended for 10 extensions or users or less. You can increase it by 
putting SQLite in a ram disk with backups that are performed often just as was 
suggested. The other even better option is to move a database that is designed 
for a higher load I recommend PostgreSQL.

Original comment by markjcrane@gmail.com on 17 Jan 2015 at 8:00