Conflict between atomic update and highlighting constraints
Hi, I am running into a conflict between two constraints. Atomic updates require copy-field destinations to be stored=false. However, if we want to use these copy-field destination fields in highlighting then they need to be stored=true. How to resolve this conflict?
Re: Solr custom query component does not return correct facet counts
I resolved this issue by extending the class to SearchComponent instead of
QueryComponent. It seems that SearchComponent sits at a higher level of
abstraction than QueryComponent and is useful when you want to work on a
layer above shards.
On Wed, Mar 10, 2021 at 8:05 PM gnandre wrote:
> I have a simple Solr query component that does some exact match processing
> by replacing qf and pf params in incoming search requests with new values
> that point to the fields that do not do stemming, synonymization etc.
>
> This works as expected. However in a distributed context (not using
> SolrCloud, just using shards param), although it works as expected, the
> facets counts are off.
>
> Facet counts are double of what they should be. Also, I noticed that I get
> two "response" objects in JSON response in a distributed context. Please
> note that I have already added following so that I do not get two responses
> back:
>
> @Override
> public void process(ResponseBuilder rb) throws IOException
> {
> // do nothing - needed so we don't execute the query here.
> }
>
> This is what my prepare function looks like:
> @Override
> public void prepare( ResponseBuilder rb ) throws IOException
> {
> if (exactMatchQueryProcessor != null) {
> exactMatchQueryProcessor.modifyForExactMatch(rb);
> }
> }
>
Error deleting zk node recursively - SolrCLI
I am getting exception trying to remove a zookeeper node. The node is old solr’s chrot (condatining data of one node). Exception in thread "main" java.lang.StackOverflowError at org.apache.zookeeper.ClientCnxn$Packet.(ClientCnxn.java:280) at org.apache.zookeeper.ClientCnxn.queuePacket(ClientCnxn.java:1594) at org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1520) at org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1512) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:2587) at org.apache.solr.common.cloud.SolrZkClient.lambda$getChildren$4(SolrZkClient.java:327) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71) at org.apache.solr.common.cloud.SolrZkClient.getChildren(SolrZkClient.java:327) at org.apache.solr.common.cloud.ZkMaintenanceUtils.traverseZkTree(ZkMaintenanceUtils.java:407) at org.apache.solr.common.cloud.ZkMaintenanceUtils.clean(ZkMaintenanceUtils.java:238) at org.apache.solr.common.cloud.ZkMaintenanceUtils.lambda$clean$1(ZkMaintenanceUtils.java:244) at org.apache.solr.common.cloud.ZkMaintenanceUtils.traverseZkTree(ZkMaintenanceUtils.java:422) at org.apache.solr.common.cloud.ZkMaintenanceUtils.clean(ZkMaintenanceUtils.java:238) at org.apache.solr.common.cloud.ZkMaintenanceUtils.lambda$clean$1(ZkMaintenanceUtils.java:244) at org.apache.solr.common.cloud.ZkMaintenanceUtils.traverseZkTree(ZkMaintenanceUtils.java:422) at org.apache.solr.common.cloud.ZkMaintenanceUtils.clean(ZkMaintenanceUtils.java:238)
Re: Location of Solr 9 Branch
And to add to your confusion: * the solr repo was just split from the lucene-solr repo * the "master" branch was renamed "main" ... https://gitbox.apache.org/repos/asf#solr https://github.com/apache/solr/tree/main : Date: Tue, 2 Mar 2021 15:54:10 -0500 : From: Houston Putman : Reply-To: solr-u...@lucene.apache.org : To: solr-u...@lucene.apache.org : Subject: Re: Location of Solr 9 Branch : : Solr 9 is an unreleased major version, so it lives in *master*. Once the : release process starts for Solr 9, it will live at *branch_9x*, and *master* : will host Solr 10. : : On Tue, Mar 2, 2021 at 3:49 PM Phill Campbell : wrote: : : > I have just begun investigating Solr source code. Where is the branch for : > Solr 9? : > : > : > : -Hoss http://www.lucidworks.com/
Distributed group query, if rename the unique key field name, will be java.lang.NullPointerException.
Hi:
Distributed group query, if rename the unique key field name, will be
java.lang.NullPointerException.
Because of without StoredFieldsShardResponseProcessor processing rename.
Can I create an issue to fix it?
query("q", "*:*", "rows", 100, "fl", “aliasName:id," + i1, "group", "true",
"group.field", i1, "group.limit", -1, "sort", i1 + " asc, id asc");
ERROR (qtp561770048-47) [x:collection1 ] o.a.s.h.RequestHandlerBase
java.lang.NullPointerException
at
org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:45)
at
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:615)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:598)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:488)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2609)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:794)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:567)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:518)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:432)
at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:166)
at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1612)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1582)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
at
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:766)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:773)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:905)
at java.base/java.lang.Thread.run(Thread.java:832)
Sincerely yours
Dawn
