Received-SPF: pass (mxus2: domain of riseup.net designates 204.13.164.18 as
	permitted sender) client-ip=204.13.164.18;
	envelope-from=micah@riseup.net; helo=mx1.riseup.net; 
From: micah <micah@riseup.net>
To: notmuch@notmuchmail.org
Date: Sat, 02 Jan 2010 13:16:12 -0500
Message-ID: <87zl4w4bkj.fsf@lillypad.riseup.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"
Subject: [notmuch] Queue updates to eliminate write-lock errors
Precedence: list

--=-=-=


I'm sure we are all seeing these occasionally:

notmuch-call-notmuch-process: A Xapian exception occurred opening database: Unable to get write lock on .... : already locked

It happens when you try to make a change while 'notmuch new' is being
run, which is regularly. Typically a 'notmuch new' process doesn't take
that long (especially if you are running the newer xapian libraries that
fix that bug), but I still find that I am getting that error fairly
regularly. It could be because I have a somewhat slow laptop, which has
limited memory, CPU and a slow disk, so these updates take longer so I
hit that race more frequently than others.

In any case, I am sure people have figured out the best way to deal with
this already, just the work has to be done, but in case it hasn't been
floated yet, what about a queueing layer that accepts interactive
changes and attempts to apply them to the backend, backing off and
retrying until it can get the xapian lock. That way we can merrily go
along and make changes without hitting this locking problem. These
changes might have a minor delay before they are applied (until the
queue has been flushed), but it would be the same amount of time that we
have to wait now, just without the write-lock error.

micah

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJLP41sAAoJEIy/mjIoYaeQp2QP/iP6POqncwL/1YG/j7mUcfJz
or9Bkpd7cguLo8uZGGryLo5w9oFspZT+VuDBOIzTp8GmRRFXiZ5WopVFhqKG7V8d
hL9pa0ULKnP5XG79cRW/3z4pX4EeA2v6CUs6mzlOy+Z/TiFH9dlFzAMuQrdvSEps
KE2mkAFd1eTaK1aVWlpi9n3Q7Dre44nt3Qy1NJ5Se/nfB3XWkMtqb3bSoF67fNN7
vHI1+W5w5MdPtTcgzWU/LLML3LrbHl52Jl4FtwOztKbuk3dFNEPhPWLPZPZfVGM6
0kcOy5MGcwru2TyF+6zjkhHbsQmZxksYmA+8B34szqb9UibKzmq1G7RkolQ6VJxL
Ds3IUInQHz6zKlWxaGGRtt56jtCeeL0pSnIhSgiUR/beitA/QeqlfGFO00QO2ci9
tMwB2tjlCmktf1qORCjvrWshU9qEGqwh3Y6dia3OM82nDVVmbMH5GLaXFhifapv2
2i3vr6h1CMIMDlXUXwMFWbqGxtybQowWmLzC5nTHDyCP8cCIUNSwPk4P+TEpKo0G
aOdd/nYlIiz1vN0VQVGSWp/bwtWCQPGK/4eN7jtDJl1C2Xek3m7adjUJYIwcnD/C
U556f86GPIdzhzzV174eFl4S2r2sCNlBj4vLR3OXJmxYxHZQp9Tm3BSPyAb4kbEi
4tDcZAonV5CF1MtE2/pE
=Y46q
-----END PGP SIGNATURE-----
--=-=-=--