[
https://issues.apache.org/jira/browse/OAK-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4211:
--------------------------------
Attachment: OAK-4211-02.patch
The current patch is currently incomplete, so I attach a second version of it.
The {{FileChannel}} has its own {{close}} method, so I make sure that this is
called as well. Moreover, I release the reference to the {{MappedByteBuffer}},
otherwise the buffer could never be unmapped from memory.
There is an additional problem with the memory-mapped files on Windows, as
explained by [this JDK bug|http://bugs.java.com/view_bug.do?bug_id=4724038].
Since there is no explicit {{munmap}} for memory-mapped files, sometimes the
process holds a reference to the buffer for too long, preventing the file from
being deleted. I spotted this while taking care of the leftovers of some
integration tests on Windows. I will open a separate issue for this.
> FileAccess.Mapped leaks file channels
> --------------------------------------
>
> Key: OAK-4211
> URL: https://issues.apache.org/jira/browse/OAK-4211
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-next
> Reporter: Michael Dürig
> Fix For: 1.6
>
> Attachments: OAK-4211-02.patch, OAK-4211.patch
>
>
> {{FileAccess.Mapped}} seems to leak {{FileChannnel}} instances. The file
> channels are acquired in the constructor but never release.
> FYI [~alex.parvulescu], [~frm]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
