You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mikhail Khludnev (JIRA)" <ji...@apache.org> on 2016/12/23 20:41:58 UTC
[jira] [Comment Edited] (SOLR-9448) [subquery] calls another
collection fails with "undefined field" or NPE from mergeIds
[ https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773633#comment-15773633 ]
Mikhail Khludnev edited comment on SOLR-9448 at 12/23/16 8:41 PM:
------------------------------------------------------------------
attaching simpler approach to reproduce:
{code}
15551 ERROR (qtp1315527986-39) [n:127.0.0.1:56344_solr c:people s:shard2 r:core_node1 x:people_shard2_replica1] o.a.s.h.RequestHandlerBase java.lang.NullPointerException
at org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:1118)
at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:763)
at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:742)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:422)
{code}
was (Author: mkhludnev):
attaching simpler approach to reproduce:
{code}
9741 ERROR (qtp1940230238-41) [n:127.0.0.1:55195_solr c:departments s:shard1 r:core_node4 x:departments_shard1_replica1] o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:294)
{code}
> [subquery] calls another collection fails with "undefined field" or NPE from mergeIds
> -------------------------------------------------------------------------------------
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 6.1, 6.2
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Attachments: SOLR-9448.patch, SOLR-9448.patch, SOLR-9448.patch
>
>
> h2.UPD
> The sentences below seems not really actual. The more objective synopsis is described in the first comment. It seems like fl=foo:\[subquery]&collection=bar can be fixed just by declaring fields in schema.
> h3. Old description
> straightforward \[subquery] implementation executes requests on a caller collection, but just hitting another one with {{caller/select?q=..&collection=callee}}. The problem is that for {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one. Another observation, at that case both single sharded collections are collocated at the same instance. Then, subquery can't be parsed if it queries a field which are absent in caller schema. All of this seems pretty strange like hitting an edge case.
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org