You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Martijn Hendriks (JIRA)" <ji...@apache.org> on 2007/08/23 10:00:41 UTC

[jira] Created: (JCR-1078) ChangeLog serialization causes cache inconsistencies

ChangeLog serialization causes cache inconsistencies
----------------------------------------------------

                 Key: JCR-1078
                 URL: https://issues.apache.org/jira/browse/JCR-1078
             Project: Jackrabbit
          Issue Type: Bug
          Components: clustering
    Affects Versions: 1.3
         Environment: Clustered Jackrabbit 1.3
            Reporter: Martijn Hendriks


The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.

The issue should be reproducable as follows:
- Setup a clustered environment with two Jackrabbit instances, say A and B.
- On instance A add a property "P" with value "x" to some node and save the session.
- On instance B read property "P" -> it will have value "x".
- On instance A delete property P and then add it again with value "y" and save the session.
- On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Commented: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522076 ] 

Dominique Pfister commented on JCR-1078:
----------------------------------------

Good observation, Martijn. In fact, putting the states in the following order back into the ChangeLog on deserialization should do the trick:

1) deleted (checks added and removed)
2) modified (checks added only)
3) added


> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>         Attachments: JCR-1078.patch
>
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Updated: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-1078:
-------------------------------

    Affects Version/s: 1.2.1
                       1.2.2
                       1.2.3
                       1.3.1
        Fix Version/s: 1.3.2

Merged to the 1.3 branch in revision 577858.

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>             Fix For: 1.3.2
>
>         Attachments: JCR-1078.patch
>
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Updated: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martijn Hendriks updated JCR-1078:
----------------------------------

    Attachment: JCR-1078.patch

Swapping the order of the serialization to:
1) serialize deletedStates
2) serialize modifiedStates
3) serialize addedStates
in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc) should work. Here's a patch for it. I tested it on the scenario from the description and it works there.

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>         Attachments: JCR-1078.patch
>
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Commented: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522058 ] 

Thomas Mueller commented on JCR-1078:
-------------------------------------

I can reproduce this problem

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Commented: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522061 ] 

Martijn Hendriks commented on JCR-1078:
---------------------------------------

I think that the following holds for a ChangeLog:

1) state \in addedStates => no deleted(state) events after the added(state) event.
2) state \in modifiedStated => no added(state) event and no deleted(state) event after the modified(state) event
3) state \in deletedStates => no added(state) event earlier

The serialization code should derive an ordering such that these properties hold.

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Resolved: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominique Pfister resolved JCR-1078.
------------------------------------

    Resolution: Fixed

Wow, that was quick! When comparing my change to yours, the only difference found was the revision number on top. Applied the patch and verified that it solves the problem.

Thanks for reporting and submitting a patch, great job!

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>         Attachments: JCR-1078.patch
>
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Assigned: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominique Pfister reassigned JCR-1078:
--------------------------------------

    Assignee: Dominique Pfister

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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


[jira] Commented: (JCR-1078) ChangeLog serialization causes cache inconsistencies

Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522086 ] 

Martijn Hendriks commented on JCR-1078:
---------------------------------------

You're welcome. Thanks for responding so quickly on this issue!

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>         Attachments: JCR-1078.patch
>
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

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