torque mailbox frequent deadlocks

[Robert Burrell Donkin <ro...@gmail.com>]

i've been going though the logs to find out why fetchpop->sieve->IMAP
hasn't been filtering mail incorrectly even though jsieve is working
very well for me.

one problem turns out to be that concurrent access to the torque
mailbox deadlocks very frequently. for example, appending whilst
another thread tries to read flags will deadlock derby forcing one
transaction to roll back.

my views on the torque mailbox design are probably well known but
since fixing them seems to require a rewrite and i'm interested in a
JCR backed solution i've been trying to ignore them.

if anyone out there is interested in running IMAP against a database
then now would be a good time to step forward ;-)

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: torque mailbox frequent deadlocks

[Robert Burrell Donkin <ro...@gmail.com>]

On 7/30/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> i've been going though the logs to find out why fetchpop->sieve->IMAP
> hasn't been filtering mail incorrectly even though jsieve is working
> very well for me.
>
> one problem turns out to be that concurrent access to the torque
> mailbox deadlocks very frequently. for example, appending whilst
> another thread tries to read flags will deadlock derby forcing one
> transaction to roll back.
>
> my views on the torque mailbox design are probably well known but
> since fixing them seems to require a rewrite and i'm interested in a
> JCR backed solution i've been trying to ignore them.
>
> if anyone out there is interested in running IMAP against a database
> then now would be a good time to step forward ;-)

messages cannot be stored concurrently with IMAP read operations.
using SEDA this could be managed by intelligent scheduling on the data
access queue but the mailbox API used by SieveToMutliMailbox has not
been designed with asynchronous operations in mind.

i can't see any alternative to some form of ugly synchronization
across all torque mailbox instances. i suppose that the classic
solution would be read and write locks for all threads. concurrent
utils ReadWriteLock seems suitable (probably the
ReentrantWriterPreferenceReadWriteLock implementation).

unless anyone jumps in with a better solution (or improvements to this
plan), i'll implement as outlined above.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org