[
https://issues.apache.org/jira/browse/LUCENE-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893615#action_12893615
]
Jason Rutherglen commented on LUCENE-2575:
------------------------------------------
{quote}Where is there a concurrency problem? Is it a JMM
visibility issue of writes from one thread vs reads, in a shared
byte[]?{quote}
For example if the 1st dimension of the byte array increases,
how is that made visible while it's also being read? In
addition, there's the JMM issue of the actual byte[]s that hold
the data (ie, if we're writing to a byte[] there's no guarantee
as to when those bytes will be available to reading threads).
We're writing segments to the Directory API today, it seems we
should be able to also write to a virtual ram filesystem (a
concurrent RAMDir?) with some basic block level locking
semantics (encapsulated in a flush method). Then we could safely
and concurrently read from this new RAMDr. Couldn't we also use
the RAMDir to interleave IndexOutputs, or provide an abstraction
that performs actual the interleaving?
> 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
