You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Benoit Tellier <be...@minet.net> on 2014/12/17 19:05:20 UTC

[PATCH] Fix CassandraModSeqProvider

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I found in the current Cassandra implementation a possible data race
during modseq generation. It is located in james-mailbox project and in
cassandra subproject.

The previous implementation, relying on Cassandra counters, first
increments the modseq for the current mailbox in a first request to
Cassandra, and in a second time is reading the new modseq value, using a
second request.

If two mails for the same mailbox are received on different servers at
the same time, it is possible that both server proceed to the first
operation in the same time, setting ModSeq value from n to n+2. During
the second operation, they will return both the n+2 value, and both
mails will have the same modseq.



To solve the bug, I used Cassandra's lightweight tansactions :
 - I created a table dedicated to modseq storage ( I needed a separated
table as in unit tests modseq operations are used with non initialised
mailbox )
 - We ensure that an entry exist for this mailbox
 - We read and update the value ( in two operations ) until our
modification is applied ( using Cassandra lightweight transactions )
 - I added a max retry parameter so that we can't dead lock. Upon
failure ( too many tries ), we throw a mailbox exception.



You will find the corresponding patch as an attachment to this current
e-mail,

Sincerly yours,

Benoit Tellier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUkcXGAAoJEKXeA9M8Xtuc+V0QAIHOpJLrcR+vTNpWsWqoC3Mr
PrjIXASsMVJPDAXbchS1sHS2u7B9XXvOGTSCVTYoB80VTKBzxX3CWaPwqEt/HiXD
FUnbdnfqpqZavAfviHAZD+p7HPgFRQWT7Fj+iF/ugZi0O74msx49GVmLKU/TzGpX
We7GESVMLfEFqLVZK3nnnL4b9HjW50HaodaWBRVhMaPkjZi274trH9elQRUqOaUC
uIxYbx7zzD6Qzg/S2LM40/iaiq/SqbYHgf30eJphKea8tguOmZSTFBYQ+SZc/smE
ZyYfc+zPSb9fiXsrJHpLnmUds6M0XpA6Ld9L517WDXhbB4hRjC31L4xPePwtDk0g
w8VN0tDIUCrGFY7xJCoL148h/+fYH2O7Sa1Uu3SkJpbPBdehv5IgrHWSkdr3oKGM
te4D9i1g1xO3pomtKXcu2L8NG7z7v43C4cLS/DlbVCGUkNb6dcrCX1FzvhjzDpJm
iJVrzbSgQ72nr6OsApbhCqH5bmAfX7ewsV/Jn0KY6CDnHI3o4jARyjJwuTeESJt8
kh06V3DbqX6YmSuRJVcIcoB9cUv/CqhSHNWqS+EwfVsYVvE/2ErukY5mhQrQ1CAx
BtA3ShN6iTGdYwf9nha+9FlHjZjhu/EI7JiuBd8FBpSUSZQytdnY1TUlHuRiDFal
ODCvx6DAi1jDecFO2x/A
=VOdc
-----END PGP SIGNATURE-----


Re: [PATCH] Fix CassandraModSeqProvider

Posted by Eric Charles <er...@apache.org>.
Can you attach the patch on a jira for review ? (if not yet done)

On 12/17/2014 07:05 PM, Benoit Tellier wrote:
>
> Hi,
>
> I found in the current Cassandra implementation a possible data race
> during modseq generation. It is located in james-mailbox project and in
> cassandra subproject.
>
> The previous implementation, relying on Cassandra counters, first
> increments the modseq for the current mailbox in a first request to
> Cassandra, and in a second time is reading the new modseq value, using a
> second request.
>
> If two mails for the same mailbox are received on different servers at
> the same time, it is possible that both server proceed to the first
> operation in the same time, setting ModSeq value from n to n+2. During
> the second operation, they will return both the n+2 value, and both
> mails will have the same modseq.
>
>
>
> To solve the bug, I used Cassandra's lightweight tansactions :
>  - I created a table dedicated to modseq storage ( I needed a separated
> table as in unit tests modseq operations are used with non initialised
> mailbox )
>  - We ensure that an entry exist for this mailbox
>  - We read and update the value ( in two operations ) until our
> modification is applied ( using Cassandra lightweight transactions )
>  - I added a max retry parameter so that we can't dead lock. Upon
> failure ( too many tries ), we throw a mailbox exception.
>
>
>
> You will find the corresponding patch as an attachment to this current
> e-mail,
>
> Sincerly yours,
>
> Benoit Tellier
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

-- 
Eric Charles

Datalayer <http://datalayer.io>
Turn Big Data into Business Value
eric@datalayer.io +32 478 555.750