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 "Tellier Benoit (JIRA)" <ji...@apache.org> on 2015/01/21 10:05:34 UTC

[jira] [Updated] (MAILBOX-209) A data race is possible with Cassandra modseq generation

     [ https://issues.apache.org/jira/browse/MAILBOX-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tellier Benoit updated MAILBOX-209:
-----------------------------------
    Attachment: fix_cassandra_modseq_provider.patch

In this patch, we first get the current modseq value. We increase it only if the value did not change. If it is the case, we can then return the incremented value. If it is not the case, we just retry.

Note a tunnable max retry parameter ( to avoid being stuck )

To validate all cassandra unit tests ( mailbox mappers espacially ), it has to behave well even if the mailbox does not exist. Hence the separated table.

> A data race is possible with Cassandra modseq generation
> --------------------------------------------------------
>
>                 Key: MAILBOX-209
>                 URL: https://issues.apache.org/jira/browse/MAILBOX-209
>             Project: James Mailbox
>          Issue Type: Bug
>            Reporter: Tellier Benoit
>         Attachments: fix_cassandra_modseq_provider.patch
>
>
> The Cassandra mailbox implementation proceed as follow to increase the modseq :
>  - a first call to Cassandra to increase the modseq value for a given mailbox
>  - a second call allow us to retrieve the current value.
> Note that you can not do it in a single call...
> In a distributed environment, imagine that :
>  - for a mailbox the current modseq is n
>  - server A increments modseq. Modseq is n+1
>  - server B increments modseq. Modseq is n+2
>  - server A and B then retrieve the modseq value and have a duplicated modseq : they for instance both can assign n+2 value to a different message.
> The problem can be solved using conditionnal updates with lightweight transactions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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