MappedReader and SegmentMeta do not completely close their files

[javastu]

By not closing the channel and then closing the RandomAccessFile (as is done in MappedWriter) the RAF's file descriptor's use count is left as 1 and the indexes file is left open and cannot be deleted.

[javastu]

I was very mistaken in my description of this "bug".

After further analysis, it became clear to me that the file descriptors that were being left open had nothing to do with Krati code, but with the nature of Memory Mapped files in Java.

Mapping a file in Java opens a file descriptor. That descriptor is not closed/freed until the buffer returned from the map method is garbage collected.

This is reported as a "bug" on Oracle/Java in more than one bug report, and it's been an open issue for quite a long time. Up till now, they have refused to fix it for reasons that you can read on those bug reports.

Unfortunately this make it very hard to clean up Krati files when they are no longer needed. And since these files tend to be large, users of Krati should have a way of cleaning them up.

I can't think of a very good solution to this issue. There is a "Sun-specific" methods you can call to forceably unmap a file. But not sure if you want to go that way.

[jingwei]

I think that going with the "sun-specific" method is not a good solution.

[javastu]

did you see what it is?

Do you have a better idea?

BTW, we are not having very good luck with Krati testing. We shove lots of key-value pairs at it and it seems to stall as it expands its storage. Is there some way to make it perform more evenly?

• Stuart

---

From: Jingwei Wu notifications@github.com
To: jingwei/krati krati@noreply.github.com
Cc: javastu goldbergstuart@yahoo.com
Sent: Tuesday, July 9, 2013 1:08 AM
Subject: Re: [krati] MappedReader and SegmentMeta do not completely close their files (#9)

I think that going with the "sun-specific" method is not a good solution.
—
Reply to this email directly or view it on GitHub.

[jingwei]

If I understood your explanation correctly, sun-specific sun.misc.Cleaner may work or may not depending on specific implementations of MappedByteBuffer. I donot really know if it is a good idea to do this.

Regarding your Krati testing, would you mind sharing some details about your data sets and which krati store are you using. More specifically, I am looking for

• the number of keys
• the avg size of keys
• the avg size of values
• numSyncBatches
• batchSize
• Segment factory
• Store type

With this information, I may be able to make some suggestions.

Thanks.

[javastu]

Might take me a few days to gather this information for you.

But I will let you in on a secret. We are playing around with MapDB - a similar toolkit. They use reflection to see if sun.misc.Cleaner is available and use it if it is.

• Stuart

---

From: Jingwei Wu notifications@github.com
To: jingwei/krati krati@noreply.github.com
Cc: javastu goldbergstuart@yahoo.com
Sent: Wednesday, July 10, 2013 12:58 AM
Subject: Re: [krati] MappedReader and SegmentMeta do not completely close their files (#9)

If I understood your explanation correctly, sun-specific sun.misc.Cleaner may work or may not depending on specific implementations of MappedByteBuffer. I donot really know if it is a good idea to do this.
Regarding your Krati testing, would you mind sharing some details about your data sets and which krati store are you using. More specifically, I am looking for
* the number of keys
* the avg size of keys
* the avg size of values
* numSyncBatches
* batchSize
* Segment factory
* Store type
With this information, I may be able to make some suggestions.
Thanks.
—
Reply to this email directly or view it on GitHub.

[jingwei]

That is cool. Look forward to hearing from you about your data sets or performance results with MapDB.