On 7/30/07, Robert Burrell Donkin <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
