[
https://issues.apache.org/jira/browse/SOLR-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386056#comment-15386056
]
Danny Teichthal commented on SOLR-7036:
---------------------------------------
[~jpswain] Hi, I'm a team member of [~mdvir1].
I suspect that the problem is that your field is defined with docValues=true.
Can you check again in your logs if you can find some error in the pattern
"Type mismatc" <your field name> "was indexed as" ..., it should be indise
class DocTermOrds.
If you also have the option to remove docValues=true from your field and test
the new method again it would be grate.
In short, the new method does not support fields with doc values.
There's a related Lucene JIRA issue that describes that about UninvertedField -
LUCENE-7119.
I see 2 options for a fix in the patch:
1. We should not allow using group.facet.method=uif on doc values field and
throw a descriptive exception on this case.
2. In case we hit a doc value field - fallback to the original method.
Personally, I prefer to throw an exception, this way new consumers of this
method will not get confused and will get a descriptive error.
The second option is used on the JSON facet API.
If you will facet on that field without grouping and set "facet.method=uif",
then FacetField.createFacetProcessor will detect that it is a docValue and fall
back to using the doc values processor instead of UIF.
Regarding the attached stacktrace:
I analyzed the stacktrace that you attached and it looks like there is only one
active thread that is waiting on a monitor for the field value cache to be
populated.
It is stuck on UnInvertedField.getUnInvertedField.
Since there's no other thread in work, it looks like there was another thread
that tried to create the uninverted field and got an exception, in this case it
will not notify other threads and thus you are stuck on wait().
I'm not familiar with the code that much, but it looks like it could be solved
if the creation of UninvertedField was inside a try/finally block and
cache.notifyAll(); was placed in the finally.
Would appreciate if you could confirm or deny this theory.
> Faster method for group.facet
> -----------------------------
>
> Key: SOLR-7036
> URL: https://issues.apache.org/jira/browse/SOLR-7036
> Project: Solr
> Issue Type: Improvement
> Components: faceting
> Affects Versions: 4.10.3
> Reporter: Jim Musil
> Assignee: Erick Erickson
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7036.patch, SOLR-7036.patch, SOLR-7036.patch,
> SOLR-7036.patch, jstack-output.txt, performance.txt, source_for_patch.zip
>
>
> This is a patch that speeds up the performance of requests made with
> group.facet=true. The original code that collects and counts unique facet
> values for each group does not use the same improved field cache methods that
> have been added for normal faceting in recent versions.
> Specifically, this approach leverages the UninvertedField class which
> provides a much faster way to look up docs that contain a term. I've also
> added a simple grouping map so that when a term is found for a doc, it can
> quickly look up the group to which it belongs.
> Group faceting was very slow for our data set and when the number of docs or
> terms was high, the latency spiked to multiple second requests. This solution
> provides better overall performance -- from an average of 54ms to 32ms. It
> also dropped our slowest performing queries way down -- from 6012ms to 991ms.
> I also added a few tests.
> I added an additional parameter so that you can choose to use this method or
> the original. Add group.facet.method=fc to use the improved method or
> group.facet.method=original which is the default if not specified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
