[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643243#comment-16643243 ] ASF GitHub Bot commented on JENA-1615: -- GitHub user dobrist opened a pull request: https://github.com/apache/jena/pull/481 JENA-1615 - Compaction leaks file descriptors Close file channel when closing a block to release open file descriptors You can merge this pull request into a Git repository by running: $ git pull https://github.com/dobrist/jena JENA-1615 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/jena/pull/481.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #481 commit 199d4f267a70627b6a79f5a3081b37ca88224921 Author: damienobrist Date: 2018-10-09T12:12:43Z JENA-1615: Close file channel when closing a block This is necessary to release open file descriptors > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Priority: Major > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643280#comment-16643280 ] Damien Obrist commented on JENA-1615: - h3. Investigation [^open_files_after_compaction_before_gc.png] shows duplicate file descriptors for some of the files. Analyzing the Java heap and playing with garbage collection, I saw that the first garbage collection after a compaction releases some of these file descriptors. This is expected as [BlockAccessMapped#_close|https://github.com/apache/jena/blob/3d456654feb2cf7617a85a5245c80b827900076f/jena-db/jena-dboe-base/src/main/java/org/apache/jena/dboe/base/file/BlockAccessMapped.java#L249] dereferences its {{MappedByteBuffers}}, whose file descriptors are subsequently closed by [FileChannelImpl#Unmapper|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/ch/FileChannelImpl.java#l784]. [^open_files_after_compaction_after_gc.png] shows that after garbage collection there is still an open file descriptor for each TDB file. It seems these are the {{FileChannelImpl}}'s [file descriptor instances|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/ch/FileChannelImpl.java#l49], which seem to be [duplicated|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/ch/FileChannelImpl.java#l900] when creating the memory mapping. The {{FileChannelImpl}} objects get [garbage-collected|https://github.com/apache/jena/blob/3f371dfa952f4af8c2f2511cf4f36e82a56f5789/jena-db/jena-dboe-base/src/main/java/org/apache/jena/dboe/base/file/BlockAccessBase.java#L169], but their file descriptors are never closed. h3. Proposed solution Based on my investigation, I think the {{BlockAccessBase}}'s {{FileChannel}} instances need to be closed before they are dereferenced. This would seem to be consistent with what is done in TDB1's [BlockAccessBase#_close|https://github.com/apache/jena/blob/0d3928eaf449e7b375038a892a6c9c3b0dd05908/jena-tdb/src/main/java/org/apache/jena/tdb/base/file/BlockAccessBase.java#L152]. I have created a pull request with the proposed fix: [https://github.com/apache/jena/pull/481] The change seems to fix the issue: using the mentioned reproduction steps with a patched Jena SNAPSHOT shows that all (but two) file descriptors are closed after the garbage collection: [^open_files_after_compaction_after_gc_with_fix.png] Please let me know what you think and thanks in advance for your feedback! > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Priority: Major > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643660#comment-16643660 ] Andy Seaborne commented on JENA-1615: - Hi there - thanks for the clear analysis and for the fix. {{node-data.bdf}} and {{prefix-data.bdf}} should be closed as well - from a code inspection, it is {{TransBinaryDataFile}} not closing the state file: {noformat} --- a/jena-db/jena-dboe-trans-data/src/main/java/org/apache/jena/dboe/trans/data/TransBinaryDataFile.java +++ b/jena-db/jena-dboe-trans-data/src/main/java/org/apache/jena/dboe/trans/data/TransBinaryDataFile.java @@ -217,6 +217,7 @@ @Override public void close() { +stateMgr.close(); binFile.close() ; } {noformat} > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Priority: Major > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644895#comment-16644895 ] Damien Obrist commented on JENA-1615: - Hi [~andy.seaborne], thanks for looking into this! Indeed these files should be closed as well. Being unfamiliar with the code, I struggled when I tried to track them down. Thanks for the fix, I have included the change in the pull request. I can confirm that with these fixes, there are no more open file descriptors for the old generation after a compaction (after garbage collection). > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Priority: Major > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646353#comment-16646353 ] Andy Seaborne commented on JENA-1615: - Thanks for the confirmation, it's very helpful to have independent verification - I'll merge the PR. > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Priority: Major > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646356#comment-16646356 ] ASF GitHub Bot commented on JENA-1615: -- Github user asfgit closed the pull request at: https://github.com/apache/jena/pull/481 > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Priority: Major > Fix For: Jena 3.10.0 > > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647555#comment-16647555 ] Damien Obrist commented on JENA-1615: - {quote}I'll merge the PR {quote} [~andy.seaborne] thanks a lot, that's great to hear! When is version 3.10.0 scheduled to be released? > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.10.0 > > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647893#comment-16647893 ] Andy Seaborne commented on JENA-1615: - Jena releases about every 3-4 months though it depends on people's availability (volunteers). You can build the source code (-Pdev will all up to Fuseki2 and is faster) or try the development snapshots built daily (maven repo [https://repository.apache.org/snapshots).] > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.10.0 > > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JENA-1615) Compaction leaks file descriptors
[ https://issues.apache.org/jira/browse/JENA-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650144#comment-16650144 ] Damien Obrist commented on JENA-1615: - [~andy.seaborne] got it, thanks for the pointers! > Compaction leaks file descriptors > - > > Key: JENA-1615 > URL: https://issues.apache.org/jira/browse/JENA-1615 > Project: Apache Jena > Issue Type: Bug > Components: Core, TDB2 >Affects Versions: Jena 3.8.0 > Environment: I reproduced the issue on the following environments: > * OS / Java: > ** MacOS 10.13.5 > Java 1.8.0_161 (Oracle) > ** Debian 9.5 > Java 1.8.0_181 (OpenJDK) > * Jena version 3.8.0 > * TDB2 mode: mapped >Reporter: Damien Obrist >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 3.10.0 > > Attachments: open_files_after_compaction_after_gc.png, > open_files_after_compaction_after_gc_with_fix.png, > open_files_after_compaction_before_gc.png, open_files_before_compaction.png > > > h3. Context > I'm using a TDB2 dataset in a long-running Scala application, in which the > dataset gets compacted regularly. After compactions, the application removes > the {{Data-}} folder of the previous generation. However, the > corresponding disk space isn't properly returned back to the OS, but is still > reported as being used by {{df}}. Indeed, {{lsof}} shows that the application > keeps open file descriptors that point to the old generation's files. Only > stopping / restarting the JVM frees the disk space for good. > h3. Reproduction steps > * Connect to an existing TDB2 dataset > {code} > val dataset = TDB2Factory.connectDataset("sample"){code} > * Check open files > [^open_files_before_compaction.png] > * Compact the dataset > {code}DatabaseMgr.compact(dataset.asDatasetGraph){code} > * Check open files (before garbage collection) > [^open_files_after_compaction_before_gc.png] > * Check open files (after garbage collection) > [^open_files_after_compaction_after_gc.png] > The last sceenshot shows that, even after garbage collection, there are still > open file descriptors pointing to the old generation {{Data-0001}}. > h3. Impact > Depending on how disk usage is being reported, this can be quite problematic. > In our case, we're running on an OpenShift infrastructure with limited > storage. After only a handful of compactions, the storage is considered full > and cannot be used anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)