james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: [MAILBOX and IMAP] Possible race-condition because of lazy fetching
Date Sat, 23 Jul 2011 14:36:59 GMT
Hi there,

comments inside..

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

Bye,
Norman

---------------------------------------------------------------------
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