[
https://issues.apache.org/jira/browse/LUCENE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362813#comment-17362813
]
Adrien Grand commented on LUCENE-9959:
--------------------------------------
bq. Is the implementation what you are expecting?
Yes, something along these lines indeed. I left some thoughts on the PR, the
main one being that we should avoid leaking logic like
checkIntegrity/clone/getMergeInstance to the IndexReader APIs.
bq. add a new API to go alongside with them, and gradually phased out the use
of the existing two
+1
bq. I'm a bit wondering why other readers from SegmentReader don't need to use
the same thread local approach
Actually e.g. doc values used to leverage thread locals until Lucene 7.0. We
removed the thread locals because Lucene 7 changed the doc values API from
being random-access (like stored fields) to being an iterator, and the iterator
API is not compatible with caching.
> Can we remove threadlocals of stored fields and term vectors
> ------------------------------------------------------------
>
> Key: LUCENE-9959
> URL: https://issues.apache.org/jira/browse/LUCENE-9959
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [~rmuir] suggested removing these threadlocals at
> https://github.com/apache/lucene/pull/137#issuecomment-840111367.
> These threadlocals are trappy if you manage many segments and threads within
> the same JVM, or worse: non-fixed threadpools. The challenge is to keep the
> API easy to use.
> We could take advantage of 9.0 to change the stored fields API?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
