directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Alderson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-894) Older concurrent changes are never replicated
Date Sat, 09 Jun 2007 23:11:28 GMT

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


Mime
View raw message