[
https://issues.apache.org/jira/browse/SOLR-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759097#comment-13759097
]
Erick Erickson commented on SOLR-2548:
--------------------------------------
[~yonik] Don't quite see what you're getting at. I understand what you're
saying about pending blocking threads loading the same field name in different
cores, good point.
But how to put a placeholder in the cache? It needs an UnInverted field as an
entry. I could add a bogus c'tor to make an degenerate UnInverted field and use
_that_, then check every time we get something out of the cache for a field in
order to see if it's the degenerate case. One could add a member var "imFake"
or something. Really the question is how to distinguish between the cache
returning null or returning something signaling "Come back later and get the
entry another thread loaded". I like the idea of not having the spare pending
set at all, one less thing to coordinate.
Or I could just make the pending bits prepend the core name to the field?
Actually, I'm beginning to wonder whether adding all this junk in is really
better than just throwing the UnInvertedFields 2-n on the floor like the
original patch did...
> Multithreaded faceting
> ----------------------
>
> Key: SOLR-2548
> URL: https://issues.apache.org/jira/browse/SOLR-2548
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 3.1
> Reporter: Janne Majaranta
> Assignee: Erick Erickson
> Priority: Minor
> Labels: facet
> Attachments: SOLR-2548_4.2.1.patch, SOLR-2548_for_31x.patch,
> SOLR-2548.patch, SOLR-2548.patch, SOLR-2548.patch, SOLR-2548.patch
>
>
> Add multithreading support for faceting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
