[
https://issues.apache.org/jira/browse/LUCENE-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801864#action_12801864
]
Paul Elschot commented on LUCENE-2222:
--------------------------------------
{quote}
I have noticed also another problem with the block index I/O and PFOR I/O. The
fixed int block index can be configured with any block size, but PFOR requires
at least a block size of 32 (and even, I think it requires a block size which
is a product of 32), otherwise the decompression do not work correctly (the
inputSize in decompressFrame is based on frameOfRef.unComprSize). There should
be a block size checking in the PFOR index I/O. Should I open a new issue ?
{quote}
I have not looked at the flex branch yet, but the PFOR implementation at
LUCENE-1410 has the possibility to encode/decode any block length. To decode
blocks that are not a multiple of 32 in size it will fall back from the faster
decoding routine (the generated code) to the general (and slow) decoding
routine at ForDecompress.decodeAnyFrame().
Lately I've been tinkering with Simple9 (LUCENE-2189) which is simpler than
PFOR but has the problem that the input block size is not known beforehand. As
far as I can see now, we might end up with a general pair of block
encoding/decoding routines that uses PFOR for longer blocks, Simple9 (or a
variant of that) for the remainder and vByte for whatever is left.
> FixedIntBlockIndexInput.Reader does not initialise 'pending' int array
> ----------------------------------------------------------------------
>
> Key: LUCENE-2222
> URL: https://issues.apache.org/jira/browse/LUCENE-2222
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: Flex Branch
> Reporter: Renaud Delbru
> Priority: Minor
> Fix For: Flex Branch
>
> Attachments: LUCENE-2222.patch, LUCENE-2222.patch, LUCENE-2222.patch
>
>
> The FixedIntBlockIndexInput.Reader.pending int array is not initialised. As a
> consequence, the FixedIntBlockIndexInput.Reader#next() method returns always
> 0.
> A call to FixedIntBlockIndexInput.Reader#blockReader.readBlock() during the
> Reader initialisation may solve the issue (to be tested).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
