[
https://issues.apache.org/jira/browse/LUCENE-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5164:
----------------------------------
Attachment: LUCENE-5164.patch
New patch:
- The NIOFS read loop was further cleaned up and simplified by using the
ByteBuffer tracking.
- The setter/getter in FSDirectory are no no-ops (deprecated)
- Every implementation has its own chunk size, which fits the underlying IO
layer. For RandomAccessFile this is 8192 bytes
I decided not to put the chunking into Buffered*, as it is still separate and
complicates code of Buffered* even more.
> Remove the OOM catching in SimpleFSDirectory and NIOFSDirectory
> ---------------------------------------------------------------
>
> Key: LUCENE-5164
> URL: https://issues.apache.org/jira/browse/LUCENE-5164
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Attachments: LUCENE-5164.patch, LUCENE-5164.patch
>
>
> Followup from LUCENE-5161:
> In former times we added the OOM cactching in NIOFSDir and SimpleFSDir
> because nobody understand why the OOM could happen on FileChannel.read() or
> SimpleFSDir.read(). By reading the Java code its easy to understand (it
> allocates direct buffers with same size as the requested length to read). As
> we have chunking now reduce to a few kilobytes it cannot happen anymore that
> we get spurious OOMs.
> In fact we might hide a *real* OOM! So we should remove it.
> I am also not sure if we should make chunk size configureable in FSDirectory
> at all! It makes no sense to me (it was in fact only added for people that
> hit the OOM to fine-tune).
> In my opinion we should remove the setter in trunk and keep it deprecated in
> 4.x. The buf size is then in trunk equal to the defaults from LUCENE-5161.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
