Does anyone understand the discussion on that ticket Sriram posted? It
sounds like they have an unmap call but they appear to be concerned about
protecting threads from one another--i.e. if one thread unmapped the file
and another mapped a different file it would show up in the old memory
mapping. This is true but in what universe are you trying to protect one
thread from another thread in the same process? If they are in different
processes then file permissions and memory protection should handle it, no?
This seems like it would only be a problem in a situation where you are
running untrusted threads in your jvm, which is not a concern we would care
to address.

Assuming we understand the issue correctly I think it would be fine to just
use reflection and force the unmap provided that this is a no-op if it

Needless to say we have not done any testing on windows, so this is good.

Another concern I have is whether the index file preallocation is working
properly? We are using RandomAccessFile.setLength(xxx) to preallocate a
sparse file. I believe NTFS does support sparse files but I'm not sure if
this method will actually do sparse allocation on Windows. If not there
could be some latency as the file is physically created which would be a

On Wed, Jul 10, 2013 at 7:59 AM, Denny Lee <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB