[
https://issues.apache.org/jira/browse/LUCENE-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907587#action_12907587
]
Michael McCandless commented on LUCENE-2575:
--------------------------------------------
Right, we over-allocate each slice according to the sizes in levelSizeArray.
For a given "stream", all of its slices but the last one will be filled in.
The interleaved slices "logically" encode many streams (one per unique term),
and all of these streams will have a "tip" slice, where any bytes written to
that stream will go.
How to make this properly concurrent is a challenge. Each reader knows its max
docID, so, it can stop reading a given stream when it hits a docID over the
max. But, because the write can go back and overwrite the last 4 bytes of a
slice (w/ the address of the next slice), we have to guard for that case (when
a reader is trying to read that slice at the same time).
> Concurrent byte and int block implementations
> ---------------------------------------------
>
> Key: LUCENE-2575
> URL: https://issues.apache.org/jira/browse/LUCENE-2575
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: Realtime Branch
> Reporter: Jason Rutherglen
> Fix For: Realtime Branch
>
>
> The current *BlockPool implementations aren't quite concurrent.
> We really need something that has a locking flush method, where
> flush is called at the end of adding a document. Once flushed,
> the newly written data would be available to all other reading
> threads (ie, postings etc). I'm not sure I understand the slices
> concept, it seems like it'd be easier to implement a seekable
> random access file like API. One'd seek to a given position,
> then read or write from there. The underlying management of byte
> arrays could then be hidden?
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
