[ 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to