[
https://issues.apache.org/jira/browse/LUCENE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972096#action_12972096
]
Yonik Seeley commented on LUCENE-2815:
--------------------------------------
bq. but I wonder whether we really should? (In fact I thought at one point we
decided to stop doing that... yet, we still are... can't remember the details;
maybe perf hit was too high eg for MTQs/Solr facets/etc.).
It wouldn't be solr facets... that code asks for fields() once up front (per
facet request) and the rest of the work will dwarf that.
I think there probably are a lot of random places that use it where the
overhead could be significant. For example IndexReader.deleteDocuments(),
ParallelReader, FuzzyLikeThisQuery, and anyone else that uses any of the static
methods on Field on a non-segment reader.
bq. What do we need to do to make the publication safe? Is making
IR.store/retrieveFields sync'd sufficient?
More than sufficient. A volatile would also work fine provided that a race
shouldn't matter (i.e. more than one MultiFields object could be constructed).
bq. Maybe MultiFields should just pre-build its Map<String,Term> on init?
Ouch... those folks with 1000s of fields wouldn't be happy about that.
> MultiFields not thread safe
> ---------------------------
>
> Key: LUCENE-2815
> URL: https://issues.apache.org/jira/browse/LUCENE-2815
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Yonik Seeley
>
> MultiFields looks like it has thread safety issues
--
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
