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.
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.
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.
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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
--
Eric Charles
http://about.echarles.net
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
