[
https://issues.apache.org/jira/browse/SOLR-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467140#comment-15467140
]
Mikhail Khludnev commented on SOLR-9448:
----------------------------------------
{code}
@Test
public void testJustCrossCollectionRequest() throws SolrServerException,
IOException {
cluster.getSolrClient().request(new QueryRequest(
params( "q","*:*",
"collection","departments")
), "people");
}
{code}
if we bypassing query parsing stage, we hit NPE in reduce phase because primary
collection ID field name is used for reducing shards results.
{quote}
[departments_shard1_replica1] webapp=/solr path=/select
params={distrib=false&_stateVer_=people:6&fl=id&fl=score&shards.purpose=4&start=0&fsv=true&collection=departments&shard.url=http://127.0.0.1:53330/solr/departments_shard1_replica1/|http://127.0.0.1:53331/solr/departments_shard1_replica2/&rows=10&version=2&q=*:*&NOW=1473159334331&isShard=true&wt=javabin}
hits=8 status=0 QTime=45
43234 ERROR (qtp2060379030-30) [n:127.0.0.1:53331_solr c:people s:shard1
r:core_node1 x:people_shard1_replica2] o.a.s.h.RequestHandlerBase
java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:1113)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:757)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:736)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:422)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2107)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:653)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
{quote}
Shouldn't it be fixed?
> [subquery] calls another collection fails with "undefined field"
> -----------------------------------------------------------------
>
> 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
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
