[jira] [Issue Comment Deleted] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ciuffetti updated SOLR-7495:
--
Comment: was deleted
(was: Hi
Great work on tracking this bug down n SOLR 7. I wonder since the ticket you
commented on is closed if the watchers will notice. If they don't respond, you
might need to open a new ticket and reference this closed ticket.
Pete
On 4/2/19, 4:25 AM, "Zhu JiaJun (JIRA)" wrote:
[External Email]
[
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D7495-3Fpage-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-26focusedCommentId-3D16807499-23comment-2D16807499=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=3tXvqjvqTGbaaxXQnMxq544ovEA8u36aLQrCw9kaYAs=
]
Zhu JiaJun edited comment on SOLR-7495 at 4/2/19 8:24 AM:
--
[~dpgove],
Probably this ticket should be reopen due to the group facet does not work
for PointField!
I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I
perform group facet on an IntPointField. Debugging into the source code, the
cause is that internally the docvalue type for PointField is "NUMERIC" (single
value) or "SORTED_NUMERIC" (multi value), while the TermGroupFacetCollector
class requires the facet field must have a "SORTED" or "SOTRTED_SET" docvalue
type:
[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_2480b74887eff01f729d62a57b415d772f947c91_lucene_grouping_src_java_org_apache_lucene_search_grouping_TermGroupFacetCollector.java-23L313=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=fM5StjIluZS8KmHQXM9dMczagulz45zL3idsHMIXdPU=]
When I change schema for all int field to TrieIntField, the group facet
then work. Since internally the docvalue type for TrieField is SORTED (single
value) or SORTED_SET (multi value).
Regarding that the "TrieField" is depreciated in Solr7, can someone help on
this grouping facet issue for PointField.
Thanks.
was (Author: jiajun):
[~dpgove],
Probably this ticket should be reopen due to the group facet does not work
for PointField!
I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I
perform group facet on an IntPointField. Debugging into the source code, the
cause is that internally the docvalue type for PointField is "NUMERIC" (single
value) or "SORTED_NUMERIC" (multi value), while the TermGroupFacetCollector
class requires the facet field must have a "SORTED" or "SOTRTED_SET" docvalue
type:
[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_2480b74887eff01f729d62a57b415d772f947c91_lucene_grouping_src_java_org_apache_lucene_search_grouping_TermGroupFacetCollector.java-23L313=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=fM5StjIluZS8KmHQXM9dMczagulz45zL3idsHMIXdPU=]
When I change schema for all int field to TrieIntField, the group facet
then work. Since internally the docvalue type for TrieField is SORTED (single
value) or SORTED_SET (multi value).
Regarding that the "TrieField" is depreciated in Solr7, can someone help on
this grouping facet issue for PointField.
Thanks.
> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D7495=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=1gJkA7gb_T22d58rVfNi6i0pl8tdxfrH5GOoP9SuRzU=
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
>Assignee: Dennis Gove
>Priority: Major
> Fix For: 6.4
>
> Attachments: SOLR-7495.patch, SOLR-7495.patch, SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
(expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
>
>
>
>
>
>
>
[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807748#comment-16807748
]
Peter Ciuffetti commented on SOLR-7495:
---
Hi
Great work on tracking this bug down n SOLR 7. I wonder since the ticket you
commented on is closed if the watchers will notice. If they don't respond, you
might need to open a new ticket and reference this closed ticket.
Pete
On 4/2/19, 4:25 AM, "Zhu JiaJun (JIRA)" wrote:
[External Email]
[
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D7495-3Fpage-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-26focusedCommentId-3D16807499-23comment-2D16807499=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=3tXvqjvqTGbaaxXQnMxq544ovEA8u36aLQrCw9kaYAs=
]
Zhu JiaJun edited comment on SOLR-7495 at 4/2/19 8:24 AM:
--
[~dpgove],
Probably this ticket should be reopen due to the group facet does not work
for PointField!
I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I
perform group facet on an IntPointField. Debugging into the source code, the
cause is that internally the docvalue type for PointField is "NUMERIC" (single
value) or "SORTED_NUMERIC" (multi value), while the TermGroupFacetCollector
class requires the facet field must have a "SORTED" or "SOTRTED_SET" docvalue
type:
[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_2480b74887eff01f729d62a57b415d772f947c91_lucene_grouping_src_java_org_apache_lucene_search_grouping_TermGroupFacetCollector.java-23L313=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=fM5StjIluZS8KmHQXM9dMczagulz45zL3idsHMIXdPU=]
When I change schema for all int field to TrieIntField, the group facet
then work. Since internally the docvalue type for TrieField is SORTED (single
value) or SORTED_SET (multi value).
Regarding that the "TrieField" is depreciated in Solr7, can someone help on
this grouping facet issue for PointField.
Thanks.
was (Author: jiajun):
[~dpgove],
Probably this ticket should be reopen due to the group facet does not work
for PointField!
I got an "Unexpected docvalues type SORTED_NUMERIC" exception when I
perform group facet on an IntPointField. Debugging into the source code, the
cause is that internally the docvalue type for PointField is "NUMERIC" (single
value) or "SORTED_NUMERIC" (multi value), while the TermGroupFacetCollector
class requires the facet field must have a "SORTED" or "SOTRTED_SET" docvalue
type:
[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_2480b74887eff01f729d62a57b415d772f947c91_lucene_grouping_src_java_org_apache_lucene_search_grouping_TermGroupFacetCollector.java-23L313=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=fM5StjIluZS8KmHQXM9dMczagulz45zL3idsHMIXdPU=]
When I change schema for all int field to TrieIntField, the group facet
then work. Since internally the docvalue type for TrieField is SORTED (single
value) or SORTED_SET (multi value).
Regarding that the "TrieField" is depreciated in Solr7, can someone help on
this grouping facet issue for PointField.
Thanks.
> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D7495=DwIFaQ=WMhnfwkfN4LR6wX29ZSgFCZf_hw4vy5MAv7iZJNaAD4=M-7jFHPsyUxbyMNcePis-V0Wc_uQNf0np-vYrNKVEww=DD6BWErn-USyqB44aV2KytEI_PqQ5jJg5dp6Vb24r0o=1gJkA7gb_T22d58rVfNi6i0pl8tdxfrH5GOoP9SuRzU=
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
>Assignee: Dennis Gove
>Priority: Major
> Fix For: 6.4
>
> Attachments: SOLR-7495.patch, SOLR-7495.patch, SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
(expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
>
>
>
>
>
>
>
[jira] [Issue Comment Deleted] (SOLR-8769) CloudMLTQParser does not use uniqueKey field name for exclusion
[
https://issues.apache.org/jira/browse/SOLR-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ciuffetti updated SOLR-8769:
--
Comment: was deleted
(was: It would appear the original fetch is also hardwired to 'id' and does not
use the name established by uniqueKey:
https://github.com/apache/lucene-solr/blob/813ca77250db29116812bc949e2a466a70f969a3/solr/core/src/java/org/apache/solr/search/mlt/CloudMLTQParser.java#L180)
> CloudMLTQParser does not use uniqueKey field name for exclusion
> ---
>
> Key: SOLR-8769
> URL: https://issues.apache.org/jira/browse/SOLR-8769
> Project: Solr
> Issue Type: Bug
>Reporter: Erik Hatcher
> Fix For: 5.5.1, 6.0
>
>
> Using the {{\{!mlt}}} query parser in cloud mode on a schema with a non-"id"
> uniqueKey, the main "like this" document won't be excluded properly due to
> this code:
> {code}
> realMLTQuery.add(createIdQuery("id", id), BooleanClause.Occur.MUST_NOT);
> {code}
> See also
> https://github.com/apache/lucene-solr/blob/813ca77250db29116812bc949e2a466a70f969a3/solr/core/src/java/org/apache/solr/search/mlt/CloudMLTQParser.java#L166
> Like SimpleMLTQParser, it needs to use the uniqueKey field with this type of
> code: {{req.getSchema().getUniqueKeyField().getName()}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8769) CloudMLTQParser does not use uniqueKey field name for exclusion
[
https://issues.apache.org/jira/browse/SOLR-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966182#comment-15966182
]
Peter Ciuffetti commented on SOLR-8769:
---
It would appear the original fetch is also hardwired to 'id' and does not use
the name established by uniqueKey:
https://github.com/apache/lucene-solr/blob/813ca77250db29116812bc949e2a466a70f969a3/solr/core/src/java/org/apache/solr/search/mlt/CloudMLTQParser.java#L180
> CloudMLTQParser does not use uniqueKey field name for exclusion
> ---
>
> Key: SOLR-8769
> URL: https://issues.apache.org/jira/browse/SOLR-8769
> Project: Solr
> Issue Type: Bug
>Reporter: Erik Hatcher
> Fix For: 5.5.1, 6.0
>
>
> Using the {{\{!mlt}}} query parser in cloud mode on a schema with a non-"id"
> uniqueKey, the main "like this" document won't be excluded properly due to
> this code:
> {code}
> realMLTQuery.add(createIdQuery("id", id), BooleanClause.Occur.MUST_NOT);
> {code}
> See also
> https://github.com/apache/lucene-solr/blob/813ca77250db29116812bc949e2a466a70f969a3/solr/core/src/java/org/apache/solr/search/mlt/CloudMLTQParser.java#L166
> Like SimpleMLTQParser, it needs to use the uniqueKey field with this type of
> code: {{req.getSchema().getUniqueKeyField().getName()}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8397) QueryScorer highlighting with join query causes classcast exception
Peter Ciuffetti created SOLR-8397:
-
Summary: QueryScorer highlighting with join query causes classcast
exception
Key: SOLR-8397
URL: https://issues.apache.org/jira/browse/SOLR-8397
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 5.3
Environment: SolrCloud 5.3.1
Reporter: Peter Ciuffetti
If you use the combination of a join query with the 'old' QueryScorer as a
highlighter, you get a classcast exception
{code}
java.lang.ClassCastException: org.apache.lucene.search.IndexSearcher cannot be
cast to org.apache.solr.search.SolrIndexSearcher
at
org.apache.solr.search.JoinQuery.createWeight(JoinQParserPlugin.java:217)
at
org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855)
at
org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838)
at
org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:131)
at
org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:106)
at
org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:119)
at
org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:62)
at
org.apache.lucene.search.highlight.QueryTermScorer.(QueryTermScorer.java:52)
at
org.apache.solr.highlight.DefaultSolrHighlighter.getQueryScorer(DefaultSolrHighlighter.java:244)
at
org.apache.solr.highlight.DefaultSolrHighlighter.getHighlighter(DefaultSolrHighlighter.java:197)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:586)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:428)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:143)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
{code}
the query parameters that will produce this are
{code}
?hl=true
=false
=somefield
={!join from=x to=y}somequery
{code}
This does not happen when the default SpanScorer is used (which happens when
hl.usePhraseHighlighter=true or is unspecified)
--
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
[jira] [Commented] (SOLR-8397) QueryScorer highlighting with join query causes classcast exception
[
https://issues.apache.org/jira/browse/SOLR-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049537#comment-15049537
]
Peter Ciuffetti commented on SOLR-8397:
---
Good point! I wasn't expecting any highlights. This was an unfortunate side
effect of our middleware always defaulting to having highlighting on unless
turned off, and also having a backwards default of usePhraseHighlighter=false.
This particular query didn't need any highlighting. But in our attempt to
upgrade from 4.10 to 5.3 I'm dealing with legacy queries embedded in various
unit tests and frontend code.
So I have already worked around this by making the default
usePhraseHighlighter=true. You can mark this bug minor or 'wont fix' if you'd
like... just thought it should be reported. Maybe others will run into it if
they use highlight queries maybe? Haven't tried this.
> QueryScorer highlighting with join query causes classcast exception
> ---
>
> Key: SOLR-8397
> URL: https://issues.apache.org/jira/browse/SOLR-8397
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 5.3
> Environment: SolrCloud 5.3.1
>Reporter: Peter Ciuffetti
>
> If you use the combination of a join query with the 'old' QueryScorer as a
> highlighter, you get a classcast exception
> {code}
> java.lang.ClassCastException: org.apache.lucene.search.IndexSearcher cannot
> be cast to org.apache.solr.search.SolrIndexSearcher
> at
> org.apache.solr.search.JoinQuery.createWeight(JoinQParserPlugin.java:217)
> at
> org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:855)
> at
> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:838)
> at
> org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:131)
> at
> org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:106)
> at
> org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:119)
> at
> org.apache.lucene.search.highlight.QueryTermExtractor.getTerms(QueryTermExtractor.java:62)
> at
> org.apache.lucene.search.highlight.QueryTermScorer.(QueryTermScorer.java:52)
> at
> org.apache.solr.highlight.DefaultSolrHighlighter.getQueryScorer(DefaultSolrHighlighter.java:244)
> at
> org.apache.solr.highlight.DefaultSolrHighlighter.getHighlighter(DefaultSolrHighlighter.java:197)
> at
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:586)
> at
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:428)
> at
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:143)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> {code}
> the query parameters that will produce this are
> {code}
> ?hl=true
> =false
> =somefield
> ={!join from=x to=y}somequery
> {code}
> This does not happen when the default SpanScorer is used (which happens when
> hl.usePhraseHighlighter=true or is unspecified)
--
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
[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15042147#comment-15042147
]
Peter Ciuffetti commented on SOLR-7495:
---
The multi value work around is not available to me because I also need the
fields affected by this bug to be sortable. And the string work around would
only give me sortable values if the int's were fixed width (some of my int
fields are, some are not).
> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
>
>
>
>
>
>
> multiValued="false" required="true"/>
> multiValued="false" required="true"/>
>
>
> stored="true"/>
>
>
>
> />
> sortMissingLast="true"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> precisionStep="0" positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> class="solr.SpatialRecursivePrefixTreeFieldType" geo="true"
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
>
> id
> name
>
>
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
>
[jira] [Created] (SOLR-7080) Can't bootstrap custom router.field from core.properties into zookeeper
Peter Ciuffetti created SOLR-7080: - Summary: Can't bootstrap custom router.field from core.properties into zookeeper Key: SOLR-7080 URL: https://issues.apache.org/jira/browse/SOLR-7080 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10 Reporter: Peter Ciuffetti When the collections API is used to create a collection with a custom router.field, this configuration detail is stored in zookeeper and is visible with action=CLUSTERSTATUS. But there is no apparent way to bootstrap this value from (say) core.properties or solrconfig.xml. In general this is an issue when trying to migrate cores to new servers or when trying to recover a completely failed zookeeper environment. But I think it should be possible to establish this configuration detail from some one of the configuration settings in either core.properties or solrconfig.xml. -- 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
[jira] [Commented] (SOLR-6160) Exception possible with group.facet, range faceting, with distributed search
[ https://issues.apache.org/jira/browse/SOLR-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14034369#comment-14034369 ] Peter Ciuffetti commented on SOLR-6160: --- Confirming that this patch has resolved the issue in the SolrCloud environment where it was initially discovered. Thanks! Let me know if you want me to post any query logs or other data from the environment. Exception possible with group.facet, range faceting, with distributed search Key: SOLR-6160 URL: https://issues.apache.org/jira/browse/SOLR-6160 Project: Solr Issue Type: Bug Affects Versions: 4.7.1 Reporter: David Smiley Attachments: SOLR-6160__bugfix_when_facet_query_or_range_with_group_facets_and_distributed.patch I'm seeing a hard to reproduce bug when the following conditions are true: * Distributed search * group=true with group.field=xxx and group.facet=true * facet=true with facet.field and facet.range On a sharded request (isShard=true, distrib=false) that has requestPurpose=GET_FIELDS, *sometimes* facet=true but sometimes it isn't. Apparently, sometimes the earlier GET_FACETS phase satisfies the faceting alone and sometimes more is done in GET_FIELDS. So *if* facet=true on such a request *and* facet.range is set (or perhaps facet.query), then the bug will hit. Specifically both the facet.range and facet.query logic will conditionally call SimpleFacets.getGroupedFacetQueryCount, and both will conditionally do so when they detect that group.field has been set. BUT, for a GET_FIELDS shard request, the group parameter flag is explicitly removed from the request by StoredFieldsShardRequestFactory, effectively disabling grouping. So SimpleFacets.getGroupedFacetQueryCount will throw an error. The error is that group.field hasn't been set which technically isn't true. It's 100% reproducible on my customer's system. Reproducing it is tricky because it's not going to happen if the faceting logic doesn't happen on GET_FIELDS, which doesn't seem to happen often. I found that for a test query if I changed the facet.limit to a sufficiently high number then it trips, but if it's low then it doesn't. I presume this has something to do with refining faceting counts such that a higher facet.limit increases the chance that the coordinating node (what do we call that?) will need to ask a shard for more counts beyond which was provided on the initial GET_FACETS phase. If anyone has pointers on how to reproduce this (such as in a test!), then that would help. Even though I don't have 100% understanding of the bug and have yet to reproduce it with test data, it seems to me the bug might be as simple as having SimpleFacets.getGroupedFacetQueryCount retrieve the group.field parameter directly from parameters instead of possibly failing to find it in rb.GetGroupingSpec() (because group wasn't set). After all, that is how the callers of this method determine wether or not they want to get a grouped query count. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
