Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1B0229DD8 for ; Thu, 12 Apr 2012 19:11:09 +0000 (UTC) Received: (qmail 98145 invoked by uid 500); 12 Apr 2012 19:11:05 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 98095 invoked by uid 500); 12 Apr 2012 19:11:05 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 98082 invoked by uid 99); 12 Apr 2012 19:11:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2012 19:11:05 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dmitry.kan@gmail.com designates 209.85.160.176 as permitted sender) Received: from [209.85.160.176] (HELO mail-gy0-f176.google.com) (209.85.160.176) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Apr 2012 19:10:17 +0000 Received: by ghbz10 with SMTP id z10so1687590ghb.35 for ; Thu, 12 Apr 2012 12:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NO/LpxW8e9XqBtIQGVAKFWhzh5B2ii8rtEpjKpwFl74=; b=yU4U/TM+OmVJQPV7L5kmT5zAOvXxFW7qbw6v6GwPdXDNiOhiI6xSM8TWf8OneKRsta 6BUUaxjiJhUwEnaYQlU+HLyfyjFCduC+RjImejlqI+PRi/6bbI6CTCkdImozvoLsHJkm +h917H3a5KkVhng4n+J5sU3LWeSTPbznUvRMYnAAIxpisW4MZkbmSJyZgawmPKGN1EaA ALftSESOaJNSDxhHaqHKHR+1lWcuv8iinLQVadxjJVRSGEIVPp1fvQ94l5MeNsthT/UV mjxWCMDXvXcnAFd0yZrFPqSVKU+LNgyres14yIDu8YABJWrcjfnvHwStlk0nznajFArf yvgQ== MIME-Version: 1.0 Received: by 10.236.170.165 with SMTP id p25mr3121547yhl.123.1334257796618; Thu, 12 Apr 2012 12:09:56 -0700 (PDT) Received: by 10.146.96.8 with HTTP; Thu, 12 Apr 2012 12:09:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 22:09:56 +0300 Message-ID: Subject: Re: solr 3.4 with nTiers >= 2: usage of ids param causes NullPointerException (NPE) From: Dmitry Kan To: solr-user@lucene.apache.org Content-Type: multipart/alternative; boundary=20cf305b0ab00197fa04bd801a27 X-Virus-Checked: Checked by ClamAV on apache.org --20cf305b0ab00197fa04bd801a27 Content-Type: text/plain; charset=UTF-8 Mikhail, Thanks for sharing your thoughts. Yes I have tried checking for NULL and the entire chain of queries between tiers seems to work. But I suspect, that some docs will be missing. In principle, unless there is an OutOfMemory or a shard down, the doc ids should be retrieving valid documents. So this is just a design, as Yonik pointed out. I would be willing to contribute a patch, it is just an issue of understanding what exactly should be fixed in the architecture, and I suspect it isn't a small change.. Dmitry On Thu, Apr 12, 2012 at 9:22 PM, Mikhail Khludnev < mkhludnev@griddynamics.com> wrote: > Dmitry, > > The last NPE in HighlightingComponent is just a sad coding issue. > few rows later we can see that developer expected to have some docs not > found > // remove nulls in case not all docs were able to be retrieved > rb.rsp.add("highlighting", SolrPluginUtils.removeNulls(new > SimpleOrderedMap(arr))); > But as you already know he forgot to check if(sdoc!=null){. > Is there anything that stopping you from contributing the patch, beside of > the lack of time, of course? > > about the core issue I can't get into it and, particularly, how the using > disjunction query in place of IDS can help you. Could you please provide > more detailed info like stacktraces, etc. Btw, have you checked trunk for > your case? > > On Thu, Apr 12, 2012 at 7:08 PM, Dmitry Kan wrote: > > > Can anyone help me out with this? Is this too complicated / unclear? I > > could share more detail if needed. > > > > On Wed, Apr 11, 2012 at 3:16 PM, Dmitry Kan > wrote: > > > > > Hello, > > > > > > Hopefully this question is not too complex to handle, but I'm currently > > > stuck with it. > > > > > > We have a system with nTiers, that is: > > > > > > Solr front base ---> Solr front --> shards > > > > > > Inside QueryComponent there is a method > > createRetrieveDocs(ResponseBuilder > > > rb) which collects doc ids of each shard and sends them in different > > > queries using the ids parameter: > > > > > > [code] > > > sreq.params.add(ShardParams.IDS, StrUtils.join(ids, ',')); > > > [/code] > > > > > > This actually produces NPE (same as in > > > https://issues.apache.org/jira/browse/SOLR-1477) in the first tier, > > > because Solr front (on the second tier) fails to process such a query. > I > > > have tried to fix this by using a unique field with a value of ids ORed > > > (the following code substitutes the code above): > > > > > > [code] > > > StringBuffer idsORed = new StringBuffer(); > > > for (Iterator iterator = ids.iterator(); > > iterator.hasNext(); > > > ) { > > > String next = iterator.next(); > > > > > > if (iterator.hasNext()) { > > > idsORed.append(next).append(" OR "); > > > } else { > > > idsORed.append(next); > > > } > > > } > > > > > > sreq.params.add(rb.req.getSchema().getUniqueKeyField().getName(), > > > idsORed.toString()); > > > [/code] > > > > > > This works perfectly if for rows=n there is n or less hits from a > > > distributed query. However, if there are more than 2*n hits, the > querying > > > fails with an NPE in a completely different component, which is > > > HighlightComponent (highlights are requested in the same query with > > > > > > hl=true&hl.fragsize=50000&hl.requireFieldMatch=true&hl.fl=targetTextField): > > > > > > SEVERE: java.lang.NullPointerException > > > at > > > > > > org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:161) > > > at > > > > > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295) > > > at > > > > > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > > > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1368) > > > at > > > > > > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356) > > > at > > > > > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252) > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > > > at > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > > > at > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > > > at > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > > > at > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > > at > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > at > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > > > at > > > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) > > > at > > > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) > > > at > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > > > at java.lang.Thread.run(Thread.java:619) > > > > > > It sounds like the ids of documents somehow get shuffled and the > > > instruction (only a hypothesis) > > > > > > [code] > > > ShardDoc sdoc = rb.resultIds.get(id); > > > [/code] > > > > > > returns sdoc=null, which causes the next line of code to fail with an > > NPE: > > > > > > [code] > > > int idx = sdoc.positionInResponse; > > > [/code] > > > > > > Am I missing anything? Can something be done for solving this issue? > > > > > > Thanks. > > > > > > -- > > > Regards, > > > > > > Dmitry Kan > > > > > > > > > > > -- > > Regards, > > > > Dmitry Kan > > > > > > -- > Sincerely yours > Mikhail Khludnev > gedel@yandex.ru > > > > -- Regards, Dmitry Kan --20cf305b0ab00197fa04bd801a27--