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-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org
-- Eric Charles Datalayer <http://datalayer.io> Turn Big Data into Business Value e...@datalayer.io +32 478 555.750
