[jira] Commented: (DIRSERVER-894) Older concurrent changes are never replicated

["Martin Alderson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRSERVER-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503127 ] 

Martin Alderson commented on DIRSERVER-894:
-------------------------------------------

During a chat with Emmanuel L. and Alex K. I think we managed to define this problem well and I'll take a stab at recording it here:

1. We start with two servers, A and B in a competely consistent state.
2. We have an entry, someEntry, that has an entryCSN attribute of A:1234 (indicating it was last modified by server A at local time 1234).
2. A telephoneNumber attribute is modified in someEntry on server A.  The entryCSN on A for someEntry is now A:1345.
3. A faxNumber attribute is modified in someEntry on server B.  The entryCSN on B for someEntry is now B:1456.
4. Server B sends its changes to A.  Server A now has the updated telephoneNumber, faxNumber and an entryCSN of B:1456.
5. Server A sends its changes to B.  Server B does not execute the operation as the new entryCSN is lower than the current entryCSN.

The replication has succeeded, but the two servers are in an inconsistent state.

Note: steps 4 and 5 could have been executed in any order (or even at exactly the same time).  It doesn't make a difference to the problem.

The code that is causing this behaviour is org.apache.directory.mitosis.operation.support.EntryUtil.isEntryUpdatable, called by org.apache.directory.mitosis.operation.AttributeOperation.execute0.

To fix this problem I think in step 5 server B will need to work out the value entryCSN was at the time the attribute in question (in this case telephoneNumber) was last modified, and compare that with the incoming log's entryCSN  rather than just using the current entryCSN.  I believe this will require the addition of a couple of extra columns to the backend replication logs database.  These columns would be for attribute name and modification type.


> Older concurrent changes are never replicated
> ---------------------------------------------
>
>                 Key: DIRSERVER-894
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-894
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: mitosis
>    Affects Versions: 1.5.0
>            Reporter: Martin Alderson
>
> When a (non-conflicting) change is made in two replica peer servers (A and B) at once, A's changes are replicated to B, but B's changes are never replicated to A.  This leads to inconsistent trees.  The two changes made can be totally unrelated (e.g. setting an attribute in two separate objects).
> This is easy to reproduce by having two replica servers set up, disabling the network link, making a separate change on each server,then re-enabling the network link.  Only one server will have both changes, the other will only have its own change.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.