sing Solr or Elasticsearch on multiple machines).
The bad thing on Windows is: You cannot use another IO system:
- NIOFSDirectory is too slow (Windows bug with multithreaded access) - on Linux
one may use NIOFSDirectory instead of MMapDirectory if you run out of virtual
address space
- SimpleFSDirector
t any discussion of ulimits is moot, right?
From: "Uwe Schindler"
To:
Date: 02/24/2017 06:22 PM
Subject:RE: MappedByteBuffer duplicates
Hi,
You did not give us all information. So I can only give some hints,
because there could be multiple causes for your probl
e
> From: "Uwe Schindler"
> To:
> Date: 02/24/2017 01:39 PM
> Subject:RE: MappedByteBuffer duplicates
>
>
>
> Hi,
>
> that is not an issue, the duplicates are required for so called IndexInput
> clones and splices. Every search request
e
> MappedByteBuffer
> objects are being retained.
>
>
>
>
>
> From: "Uwe Schindler"
> To:
> Date: 02/24/2017 01:39 PM
> Subject:RE: MappedByteBuffer duplicates
>
>
>
> Hi,
>
> that is not an issue, the duplicates are required for
eBuffer
objects are being retained.
From: "Uwe Schindler"
To:
Date: 02/24/2017 01:39 PM
Subject:RE: MappedByteBuffer duplicates
Hi,
that is not an issue, the duplicates are required for so called IndexInput
clones and splices. Every search request will create
y, February 24, 2017 7:19 PM
> To: java-user@lucene.apache.org
> Subject: MappedByteBuffer duplicates
>
> We have a Lucene engine that creates MappedByteBuffer objects when
> creating the Lucene index. I don't know Lucene well enough to know if
> this standard behavior.
>
We have a Lucene engine that creates MappedByteBuffer objects when
creating the Lucene index. I don't know Lucene well enough to know if
this standard behavior.
The mapped files are being created by Lucene, via the JRE's NIO APIs
native file mapping underneath each MappedByteBuffer object. We
