[
https://issues.apache.org/jira/browse/LUCENE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386614#comment-17386614
]
Zach Chen commented on LUCENE-9959:
-----------------------------------
{quote}I had put it on hold to see whether we should explore changing the API
like you did rather than still caching stored fields readers per thread but
removing as much state as possible like my PR does.
{quote}
I see. Thanks for the clarification!
{quote}If the new API proves controversial, I'd be open to an alternative that
would consist of keeping the previous API and pulling a new TermVectorsReader
(resp. StoredFieldsReader) internally every time that term vectors (resp.
stored fields) are requested instead of the previous approach that consisted of
caching instances in a threadlocal.
{quote}
+1. Do we want to try this different approach for stored field, and see how it
compares with the new API for term vector (which may create inconsistency
between APIs for the two, but hopefully temporarily) ?
> 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: 8h 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
