Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Duplicate
    • Affects Version/s: 1.4
    • Fix Version/s: None
    • Component/s: None
    • Environment:

      Description

      When we use GarbageCollector on a 42Gb datastore, GarbageCollector erase all data.
      Back with node, none have any longer data : jcr:data was removed as data in datastore no longer exist.
      On some smaller test repository, this trouble does not occur.

      We will try to update Jackrabbit version, but at least it could be "good" to be sure what is really the trouble with GC in Jackrabbit 1.4.5 so that we can be sure that updating it will really fix that.

      Thanks.

        Activity

        Cédric Chantepie created issue -
        Hide
        Thomas Mueller added a comment -

        I can not reproduce this problem. Please see:
        http://wiki.apache.org/jackrabbit/QuestionsAndAnswers#Reporting_Problems

        What we need is a simple, standalone test case that reproduces the problem.

        Show
        Thomas Mueller added a comment - I can not reproduce this problem. Please see: http://wiki.apache.org/jackrabbit/QuestionsAndAnswers#Reporting_Problems What we need is a simple, standalone test case that reproduces the problem.
        Thomas Mueller made changes -
        Field Original Value New Value
        Resolution Cannot Reproduce [ 5 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Cédric Chantepie added a comment -

        I'm still able to reproduce this trouble with the 42Gb datastore.
        I've been able to do it once with a smaller datastore, I will try to figure out what is exactly its cause.

        It seems that jackrabbit-core used by my RAR is 1.4 (not 1.4.5), even if other libs are 1.4.5.

        Getting jackrabbit-1.4 from SVN, I've some doubt about something in org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager::getAllNodeIds :
        --> Statement stmt = connectionManager.executeStmt(sql, keys, false, maxCount + 10);
        With "+ 10", infinite maxCount (0) is turned in 10, so as far as I understand, getAllNodeIds asks its connectionManager to get all nodes, but with a query whose result is limited to 10 rows.

        If I'm right, GarbageCollector using getAllNodesIds from given IterablePersistenceManager (scanPersistenceManagers) doesn't "really" get all nodes (due to rows limit), and so only some nodes are marked (date updated). Nodes not marked (not included in retrieved rows), are then considered as removable by the deleteUnused method of GarbageCollector.

        Show
        Cédric Chantepie added a comment - I'm still able to reproduce this trouble with the 42Gb datastore. I've been able to do it once with a smaller datastore, I will try to figure out what is exactly its cause. It seems that jackrabbit-core used by my RAR is 1.4 (not 1.4.5), even if other libs are 1.4.5. Getting jackrabbit-1.4 from SVN, I've some doubt about something in org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager::getAllNodeIds : --> Statement stmt = connectionManager.executeStmt(sql, keys, false, maxCount + 10); With "+ 10", infinite maxCount (0) is turned in 10, so as far as I understand, getAllNodeIds asks its connectionManager to get all nodes, but with a query whose result is limited to 10 rows. If I'm right, GarbageCollector using getAllNodesIds from given IterablePersistenceManager (scanPersistenceManagers) doesn't "really" get all nodes (due to rows limit), and so only some nodes are marked (date updated). Nodes not marked (not included in retrieved rows), are then considered as removable by the deleteUnused method of GarbageCollector.
        Hide
        Cédric Chantepie added a comment -

        Can be reproduced by reporter (me). Trying to make a testcase that can be uploaded there. Really need to figure out whether the cause was fixed by newer Jackrabbit revision, as this trouble makes datastore remove active data.

        Show
        Cédric Chantepie added a comment - Can be reproduced by reporter (me). Trying to make a testcase that can be uploaded there. Really need to figure out whether the cause was fixed by newer Jackrabbit revision, as this trouble makes datastore remove active data.
        Cédric Chantepie made changes -
        Resolution Cannot Reproduce [ 5 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Cédric Chantepie made changes -
        Affects Version/s 1.4 [ 12312447 ]
        Affects Version/s core 1.4.5 [ 12313163 ]
        Hide
        Thomas Mueller added a comment -

        There are other problems with version 1.4.x, see also JCR-1414 and specially JCR-2063, which was not backported to 1.4.x. See also the comment there for a workaround.

        Please re-open the bug if you can still reproduce it.

        Show
        Thomas Mueller added a comment - There are other problems with version 1.4.x, see also JCR-1414 and specially JCR-2063 , which was not backported to 1.4.x. See also the comment there for a workaround. Please re-open the bug if you can still reproduce it.
        Thomas Mueller made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Show
        Cédric Chantepie added a comment - I think the main cause for this trouble is there : http://svn.apache.org/viewvc/jackrabbit/branches/1.4/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.java?p2=%2Fjackrabbit%2Fbranches%2F1.4%2Fjackrabbit-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjackrabbit%2Fcore%2Fpersistence%2Fbundle%2FBundleDbPersistenceManager.java&p1=%2Fjackrabbit%2Fbranches%2F1.4%2Fjackrabbit-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fjackrabbit%2Fcore%2Fpersistence%2Fbundle%2FBundleDbPersistenceManager.java&r1=633844&r2=633843&view=diff&pathrev=633844
        Hide
        Thomas Mueller added a comment -

        Hi,

        I think your are right. I have added a comment in JCR-1414 about this.
        So I guess this makes it a duplicate of JCR-1414.

        A workaround is to disable the PersistenceManager scan using
        GarbageCollector.setPersistenceManagerScan(false),
        however this will not solve the other problems of JCR-1414 and JCR-2063.

        Show
        Thomas Mueller added a comment - Hi, I think your are right. I have added a comment in JCR-1414 about this. So I guess this makes it a duplicate of JCR-1414 . A workaround is to disable the PersistenceManager scan using GarbageCollector.setPersistenceManagerScan(false), however this will not solve the other problems of JCR-1414 and JCR-2063 .
        Hide
        Cédric Chantepie added a comment -

        I will try using Jackrabbit 2.0.0 rather than the workaround for 1.4 .
        Thanks, now it's clear.

        Show
        Cédric Chantepie added a comment - I will try using Jackrabbit 2.0.0 rather than the workaround for 1.4 . Thanks, now it's clear.
        Hide
        Jukka Zitting added a comment -

        Reopening to change resolution type to duplicate of JCR-1414.

        Show
        Jukka Zitting added a comment - Reopening to change resolution type to duplicate of JCR-1414 .
        Jukka Zitting made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Jukka Zitting made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Duplicate [ 3 ]
        Jukka Zitting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Cédric Chantepie
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development