Hi there, comments inside..
2011/7/23 Eric Charles <[email protected]>: > Hi Norman, > > I see the scenario you describe. > > I guess RFC does not say a mailbox can only be simultaneously selected by 1 > client. This would have make life easier. It says a mailbox will get accessed by many clients ;) > > I'm not sure on your sentence 'The best would be a read and a write lock. So > we could be quick in read only cases'. I would have said that when a mailbox > is read by a client, no other client can execute some writes on it, or at > least in the scenario you gave, no delete/expunge. Yeah that is what I was trying to say. So its really like the ReadWriteLock interface api docs ;) > > I think to 3 approaches (we already talked about some time ago), each > approach acting on different levels: > > 1. Let each store implements that locking at its best, sometimes with > difficulties or hack (maildir, hbase)... > > 2. Let the store module do the work and lock on read/write levels. > > 3. Have a more fine-grained approach where each mailbox would have a ongoing > imap command, each ongoing imap process allowing or forbidding other imap > command made by client. > > The last two options need to lock timeout otherwise there's a risk to have a > mailbox locked for ever. I guess the best would be to make use of the MailboxPathLocker implementation here. I think I can write some code to show you what I have in mind.. If this will not work out we can still just revert it.. > > Thx. > > On 22/07/11 19:30, Norman Maurer wrote: >> >> Hi there, >> >> today I tried to stress-test james IMAP and see how it behaves. During >> this I noticed there is a possible race-condition when concurrent >> access a mailbox from many clients. >> >> So let me explain what happens: >> >> * The first client fetch a ranges of mails (say 1:5000) >> * The second client does at the same time set the \DELETED flag on >> message with msn 4500 and then trigger "EXPUNGE". >> >> If the second client was able to execute the EXPUNGE before the first >> was trying to return message 4500 it will cause prolly cause problems >> to client one. As it will maybe try to get the headers in lazy fashion >> (like for example load them via JPA because they are declared via >> @LOB). This will fail as these rows not exist anymore. >> >> The same scenario can gives problems with maildir impls as the message >> file may not exist anymore. >> >> So to fix this we should prolly allow to Lock a Mailbox while >> accessing data from it. The best would be a read and a write lock. So >> we could be quick in read only cases. This will for sure add some >> overhead but I think its the best todo. >> >> WDYT ? >> >> Bye, >> Norman >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > -- > Eric Charles > http://about.echarles.net > Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
