On Sep 22, 2011, at 12:17 AM, Stephen A. Goss wrote:
I've seen this error twice while running integration tests (of our own application) that access Mailman 3 using the API. The load on Mailman is very light, as all requests made to the API are serial, never in parallel. Of course the various processing queues in MM3 are separate processes and could be doing work concurrently.
This probably means that one of the other processes is holding onto the database lock longer than it should, e.g. by not committing or aborting the transaction. I believe Python's sqlite layer should retry the transaction for a few seconds when it finds the database is locked. We'll have to hunt down which other process is holding the database lock (and add some debugging instrumentation if necessary). Fortunately, we don't have threads to worry about!
The backend here is SQLite, which falls over very quickly under concurrent load. If the goal here is to create a stable mailing list server, maybe SQLite is a poor default.
It could be that sqlite is only really useful for the test suite. However, Storm (our ORM layer) supports MySQL and PostgreSQL. Have you tried either of those databases? -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/856004 Title: "OperationalError: database is locked" encountered under very light load while using REST API To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/856004/+subscriptions