james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: [MAILBOX and IMAP] Possible race-condition because of lazy fetching
Date Sat, 23 Jul 2011 14:28:05 GMT
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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


-- 
Eric Charles
http://about.echarles.net

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


Mime
View raw message