Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1
    • Fix Version/s: 1.3.3
    • Component/s: versioning
    • Labels:
      None
    • Environment:
      Jackrabbit SVN Rev. 56918

      Description

      In a multithreading environment with two or more threads accessing the same version history, inconsistent state may be encountered. Concretely, the first thread is currently checking in the node to which the version history is attached while the second thread walks this same version history by means of a "self-built" iterator, which just accesses the successors of each version to get the "next" to visit.

      At a certain point the second point may encounter an ItemNotFoundException with a stack trace similar to this:

      javax.jcr.ItemNotFoundException: c9bd405b-dff4-46ef-845c-d98e073e473a
      at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:354)
      at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:230)
      at org.apache.jackrabbit.core.SessionImpl.getNodeByUUID(SessionImpl.java:494)
      at org.apache.jackrabbit.core.version.VersionImpl.getSuccessors(VersionImpl.java:86)
      ....

      It seems that the first thread has already filled the successor of the version, while the node is not yet accessible by the createItemInstance method.

      This bug seems to not be enforcible, but it is easily reproducible.

        Issue Links

          Activity

          Hide
          Jukka Zitting added a comment -

          Merged to the 1.3 branch in revision 581178.

          Show
          Jukka Zitting added a comment - Merged to the 1.3 branch in revision 581178.
          Hide
          Marcel Reutegger added a comment -

          The test runs without deadlock or errors. I will therefore set this issue to fixed.

          Show
          Marcel Reutegger added a comment - The test runs without deadlock or errors. I will therefore set this issue to fixed.
          Hide
          Marcel Reutegger added a comment -

          Added a test case for this issue:

          jackrabbit-core\src\test\java\org\apache\jackrabbit\core\ReadVersionsWhileModified.java

          At revision: 550724

          Show
          Marcel Reutegger added a comment - Added a test case for this issue: jackrabbit-core\src\test\java\org\apache\jackrabbit\core\ReadVersionsWhileModified.java At revision: 550724
          Hide
          Jukka Zitting added a comment -

          Fixing issue JCR-443 seems to have fixed a few other concurrent versioning problems. Is this issue also fixed by JCR-443?

          Show
          Jukka Zitting added a comment - Fixing issue JCR-443 seems to have fixed a few other concurrent versioning problems. Is this issue also fixed by JCR-443 ?
          Hide
          Felix Meschberger added a comment -

          Sorry again: My previous remark on "less frequently" is completely wrong. It occurrs as often as before

          Show
          Felix Meschberger added a comment - Sorry again: My previous remark on "less frequently" is completely wrong. It occurrs as often as before
          Hide
          Tobias Bocanegra added a comment -

          will investigage

          Show
          Tobias Bocanegra added a comment - will investigage
          Hide
          Felix Meschberger added a comment -

          Sorry, to say this, but the issue is only partly solved. While it occurrs less frequently than before it still occurrs.

          Again, I get the same exception at the same place at a moment where another thread is currently checkin, which modifies the successors of while the referred-to node is not (yet?) accessible.

          Here is the stack of the other thread:
          Thread [--some undisclosed name--] (Suspended)
          BDbPersistenceManager.load(NodeReferences) line: 398
          ReferenceManager.get(NodeId) line: 62
          PropertyImpl(ItemImpl).checkReferences(Iterator, Iterator, ReferenceManager) line: 635
          PropertyImpl(ItemImpl).save() line: 1132
          NodeImpl.checkin() line: 2004
          ...

          Show
          Felix Meschberger added a comment - Sorry, to say this, but the issue is only partly solved. While it occurrs less frequently than before it still occurrs. Again, I get the same exception at the same place at a moment where another thread is currently checkin, which modifies the successors of while the referred-to node is not (yet?) accessible. Here is the stack of the other thread: Thread [--some undisclosed name--] (Suspended) BDbPersistenceManager.load(NodeReferences) line: 398 ReferenceManager.get(NodeId) line: 62 PropertyImpl(ItemImpl).checkReferences(Iterator, Iterator, ReferenceManager) line: 635 PropertyImpl(ItemImpl).save() line: 1132 NodeImpl.checkin() line: 2004 ...
          Hide
          Tobias Bocanegra added a comment -

          fixed at revision 76106

          Show
          Tobias Bocanegra added a comment - fixed at revision 76106
          Hide
          Tobias Bocanegra added a comment -

          i must admit that i took no care about multihtreading until now. but of course i will do it now.

          Show
          Tobias Bocanegra added a comment - i must admit that i took no care about multihtreading until now. but of course i will do it now.

            People

            • Assignee:
              Tobias Bocanegra
              Reporter:
              Felix Meschberger
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development