[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: (was: 1.3.9) 1.4 > Implement full scale Revision GC for DocumentNodeStore > -- > > Key: OAK-1981 > URL: https://issues.apache.org/jira/browse/OAK-1981 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Marcel Reutegger > Labels: resilience, scalability > Fix For: 1.4 > > > So far we have implemented garbage collection in some form with OAK-1341. > Those approaches help us remove quite a bit of garbage (mostly due to deleted > nodes) but till some part is left > However full GC is still not performed due to which some of the old revision > related data cannot be GCed like > * Revision info present in revision maps of various commit roots > * Revision related to unmerged branches (OAK-1926) > * Revision data created to property being modified by different cluster nodes > So having a tool which can perform above GC would be helpful. For start we > can have an implementation which takes a brute force approach and scans whole > repo (would take quite a bit of time) and later we can evolve it. Or allow > system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: (was: 1.3.8) 1.3.7 > Implement full scale Revision GC for DocumentNodeStore > -- > > Key: OAK-1981 > URL: https://issues.apache.org/jira/browse/OAK-1981 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Marcel Reutegger > Labels: resilience, scalability > Fix For: 1.3.7 > > > So far we have implemented garbage collection in some form with OAK-1341. > Those approaches help us remove quite a bit of garbage (mostly due to deleted > nodes) but till some part is left > However full GC is still not performed due to which some of the old revision > related data cannot be GCed like > * Revision info present in revision maps of various commit roots > * Revision related to unmerged branches (OAK-1926) > * Revision data created to property being modified by different cluster nodes > So having a tool which can perform above GC would be helpful. For start we > can have an implementation which takes a brute force approach and scans whole > repo (would take quite a bit of time) and later we can evolve it. Or allow > system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1981: --- Fix Version/s: (was: 1.3.6) 1.3.8 > Implement full scale Revision GC for DocumentNodeStore > -- > > Key: OAK-1981 > URL: https://issues.apache.org/jira/browse/OAK-1981 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Marcel Reutegger > Labels: resilience, scalability > Fix For: 1.3.8 > > > So far we have implemented garbage collection in some form with OAK-1341. > Those approaches help us remove quite a bit of garbage (mostly due to deleted > nodes) but till some part is left > However full GC is still not performed due to which some of the old revision > related data cannot be GCed like > * Revision info present in revision maps of various commit roots > * Revision related to unmerged branches (OAK-1926) > * Revision data created to property being modified by different cluster nodes > So having a tool which can perform above GC would be helpful. For start we > can have an implementation which takes a brute force approach and scans whole > repo (would take quite a bit of time) and later we can evolve it. Or allow > system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-1981: --- Fix Version/s: (was: 1.3.8) 1.3.6 > Implement full scale Revision GC for DocumentNodeStore > -- > > Key: OAK-1981 > URL: https://issues.apache.org/jira/browse/OAK-1981 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Marcel Reutegger > Labels: resilience, scalability > Fix For: 1.3.6 > > > So far we have implemented garbage collection in some form with OAK-1341. > Those approaches help us remove quite a bit of garbage (mostly due to deleted > nodes) but till some part is left > However full GC is still not performed due to which some of the old revision > related data cannot be GCed like > * Revision info present in revision maps of various commit roots > * Revision related to unmerged branches (OAK-1926) > * Revision data created to property being modified by different cluster nodes > So having a tool which can perform above GC would be helpful. For start we > can have an implementation which takes a brute force approach and scans whole > repo (would take quite a bit of time) and later we can evolve it. Or allow > system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-1981: --- Fix Version/s: (was: 1.3.5) 1.3.8 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Labels: resilience, scalability Fix For: 1.3.8 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: (was: 1.3.4) 1.3.5 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Labels: resilience, scalability Fix For: 1.3.5 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1981: -- Fix Version/s: (was: 1.3.3) 1.3.4 Bulk move to 1.3.4 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Labels: resilience, scalability Fix For: 1.3.4 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: (was: 1.3.1) 1.3.3 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Labels: resilience, scalability Fix For: 1.3.3 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1981: -- Fix Version/s: (was: 1.3.0) 1.3.1 Bulk move to 1.3.1 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Labels: resilience, scalability Fix For: 1.3.1 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-1981: --- Labels: resilience scalability (was: ) Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Labels: resilience, scalability Fix For: 1.3.0 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: (was: 1.1.9) 1.3.0 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Assignee: Marcel Reutegger Fix For: 1.3.0 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: (was: 1.2) 1.1.9 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Fix For: 1.1.9 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1981) Implement full scale Revision GC for DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1981: -- Fix Version/s: 1.2 Implement full scale Revision GC for DocumentNodeStore -- Key: OAK-1981 URL: https://issues.apache.org/jira/browse/OAK-1981 Project: Jackrabbit Oak Issue Type: New Feature Components: mongomk Reporter: Chetan Mehrotra Fix For: 1.2 So far we have implemented garbage collection in some form with OAK-1341. Those approaches help us remove quite a bit of garbage (mostly due to deleted nodes) but till some part is left However full GC is still not performed due to which some of the old revision related data cannot be GCed like * Revision info present in revision maps of various commit roots * Revision related to unmerged branches (OAK-1926) * Revision data created to property being modified by different cluster nodes So having a tool which can perform above GC would be helpful. For start we can have an implementation which takes a brute force approach and scans whole repo (would take quite a bit of time) and later we can evolve it. Or allow system admins to determine to what level GC has to be done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
