[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Fix Version/s: 8.3
master (9.0)
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks everyone!
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Assignee: Christine Poerschke
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922627#comment-16922627
]
Christine Poerschke commented on SOLR-13240:
Attached patch rebases against the latest master which includes the above
mentioned SOLR-13736 TestPolicy.testNodeLostMultipleReplica refactor.
{quote}... My interpretion of the revised test expectations is that now then
the "a node can have 2 shardX replicas" condition is no longer being met ...
further adjustments to that sub-test might be needed to preserve the intended
coverage. ...
{quote}
The now reduced patch complexity makes it easier to reason about how the test's
"expected values" did and did not change:
* node1 is the lost node and thus r1, r3 and r5 need to be moved off it and
that continues to happen, only the order of the moves has changed.
* Previously the three moves were to node2 (two moves) and node3 (one move)
and now the moves are to node2 (one move) and node3 (two moves).
* In the list of replicas being moved we have for shard2 the r3 and r5
replicas:
** Initially it seems them now moving to node3 and node2 respectively means
that the "a node can have 2 shard2 replicas" intention of the test is no longer
being met.
** However looking closer at
[testPolicy.json|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/solrj/src/test-files/solrj/solr/autoscaling/testPolicy.json]
(and the test's previous moves off node1) it becomes clear that r6 lives on
node3 and thus r3 joining r6 on node3 would still result in two shard2 replicas
on the same (node3) node i.e. the "a node can have 2 shard2 replicas" intention
of the test continues to be met.
Assuming 'green' feedback from Lucene/Solr QA and if there are no further
comments or concern here then I'll aim to commit this ticket sometime tomorrow
afternoon (Thursday) or Friday.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
>
[jira] [Assigned] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke reassigned SOLR-13240:
--
Assignee: Christine Poerschke
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
>
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Attachment: SOLR-13240.patch
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
>
[jira] [Updated] (SOLR-13736) Reduce code duplication in TestPolicy.testNodeLostMultipleReplica
[ https://issues.apache.org/jira/browse/SOLR-13736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13736: --- Fix Version/s: 8.3 master (9.0) Resolution: Fixed Status: Resolved (was: Patch Available) > Reduce code duplication in TestPolicy.testNodeLostMultipleReplica > - > > Key: SOLR-13736 > URL: https://issues.apache.org/jira/browse/SOLR-13736 > Project: Solr > Issue Type: Test >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: master (9.0), 8.3 > > Attachments: SOLR-13736.patch > > > Splitting this refactor out from the SOLR-13240 changes in which it is > currently included. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921447#comment-16921447
]
Christine Poerschke commented on SOLR-13240:
{quote}... two small refactors to surface the sequential nature of part of the
test ...
{quote}
Just opened SOLR-13736 to split that out into a separate commit, hopefully
making it easier to see here then what the changes to the 'expected values' in
the test are.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
>
[jira] [Updated] (SOLR-13736) Reduce code duplication in TestPolicy.testNodeLostMultipleReplica
[ https://issues.apache.org/jira/browse/SOLR-13736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13736: --- Attachment: SOLR-13736.patch > Reduce code duplication in TestPolicy.testNodeLostMultipleReplica > - > > Key: SOLR-13736 > URL: https://issues.apache.org/jira/browse/SOLR-13736 > Project: Solr > Issue Type: Test >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-13736.patch > > > Splitting this refactor out from the SOLR-13240 changes in which it is > currently included. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13736) Reduce code duplication in TestPolicy.testNodeLostMultipleReplica
[ https://issues.apache.org/jira/browse/SOLR-13736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13736: --- Status: Patch Available (was: Open) > Reduce code duplication in TestPolicy.testNodeLostMultipleReplica > - > > Key: SOLR-13736 > URL: https://issues.apache.org/jira/browse/SOLR-13736 > Project: Solr > Issue Type: Test >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-13736.patch > > > Splitting this refactor out from the SOLR-13240 changes in which it is > currently included. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13736) Reduce code duplication in TestPolicy.testNodeLostMultipleReplica
Christine Poerschke created SOLR-13736: -- Summary: Reduce code duplication in TestPolicy.testNodeLostMultipleReplica Key: SOLR-13736 URL: https://issues.apache.org/jira/browse/SOLR-13736 Project: Solr Issue Type: Test Reporter: Christine Poerschke Assignee: Christine Poerschke Splitting this refactor out from the SOLR-13240 changes in which it is currently included. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8961) CheckIndex: pre-exorcise document id salvage
[
https://issues.apache.org/jira/browse/LUCENE-8961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921391#comment-16921391
]
Christine Poerschke commented on LUCENE-8961:
-
Thanks [~jpountz] for your input.
The latest attached patch facilitates potential salvaging of terms by making
the {{CheckIndex}} class extensible so that developer's own deriving classes
could:
* customise the checkIntegrity call
* filter the fields being checked
* intercept any (field,term) pairs e.g. for logging purposes
It seems to me to be a rather awkward change though and if out-of-the-box
{{CheckIndex}} would not support id salvaging then a stand-alone tool just for
that purpose might be a cleaner solution? Either way, I won't have bandwidth to
pursue this further in the near future i.e. just sharing things 'as is' in case
it might help others in the meantime.
> CheckIndex: pre-exorcise document id salvage
>
>
> Key: LUCENE-8961
> URL: https://issues.apache.org/jira/browse/LUCENE-8961
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8961.patch, LUCENE-8961.patch
>
>
> The
> [CheckIndex|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java]
> tool supports the exorcising of corrupt segments from an index.
> This ticket proposes to add an extra option which could first be used to
> potentially salvage the document ids of the segment(s) about to be exorcised.
> Re-ingestion for those documents could then be arranged so as to repair the
> data damage caused by the exorcising.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8961) CheckIndex: pre-exorcise document id salvage
[ https://issues.apache.org/jira/browse/LUCENE-8961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated LUCENE-8961: Attachment: LUCENE-8961.patch > CheckIndex: pre-exorcise document id salvage > > > Key: LUCENE-8961 > URL: https://issues.apache.org/jira/browse/LUCENE-8961 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Christine Poerschke >Priority: Minor > Attachments: LUCENE-8961.patch, LUCENE-8961.patch > > > The > [CheckIndex|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java] > tool supports the exorcising of corrupt segments from an index. > This ticket proposes to add an extra option which could first be used to > potentially salvage the document ids of the segment(s) about to be exorcised. > Re-ingestion for those documents could then be arranged so as to repair the > data damage caused by the exorcising. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13733) add more class-level javadocs for public org.apache.solr.metrics classes
[
https://issues.apache.org/jira/browse/SOLR-13733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920959#comment-16920959
]
Christine Poerschke commented on SOLR-13733:
Attached patch is partial e.g. for
[SolrRrdBackend.java|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/metrics/rrd/SolrRrdBackend.java#L32]
I couldn't easily see what a good description might be and
[JmxMetricsReporter.java|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/metrics/reporters/jmx/JmxMetricsReporter.java]
has some inner {{public interface ...}} classes/interfaces which don't yet
have javadocs.
> add more class-level javadocs for public org.apache.solr.metrics classes
>
>
> Key: SOLR-13733
> URL: https://issues.apache.org/jira/browse/SOLR-13733
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13733.patch
>
>
> Most public {{org.apache.solr.metrics}} classes already have class-level
> javadocs and adding javadocs for the few that don't have them yet could be a
> step towards {{ant precommit}} requiring(\*) javadocs (class-level only, for
> public classes, for org.apache.solr.metrics) selectively on an opt-in basis.
> (\*) = e.g. via {{solr/build.xml}} content like this:
> {code}
> dir="${javadoc.dir}/solr-core/org/apache/solr/metrics" level="class"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13733) add more class-level javadocs for public org.apache.solr.metrics classes
[
https://issues.apache.org/jira/browse/SOLR-13733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13733:
---
Summary: add more class-level javadocs for public org.apache.solr.metrics
classes (was: add class-level javadocs for public org.apache.solr.metrics
classes)
> add more class-level javadocs for public org.apache.solr.metrics classes
>
>
> Key: SOLR-13733
> URL: https://issues.apache.org/jira/browse/SOLR-13733
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13733.patch
>
>
> Most public {{org.apache.solr.metrics}} classes already have class-level
> javadocs and adding javadocs for the few that don't have them yet could be a
> step towards {{ant precommit}} requiring(\*) javadocs (class-level only, for
> public classes, for org.apache.solr.metrics) selectively on an opt-in basis.
> (\*) = e.g. via {{solr/build.xml}} content like this:
> {code}
> dir="${javadoc.dir}/solr-core/org/apache/solr/metrics" level="class"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13733) add class-level javadocs for public org.apache.solr.metrics classes
[
https://issues.apache.org/jira/browse/SOLR-13733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13733:
---
Attachment: SOLR-13733.patch
> add class-level javadocs for public org.apache.solr.metrics classes
> ---
>
> Key: SOLR-13733
> URL: https://issues.apache.org/jira/browse/SOLR-13733
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13733.patch
>
>
> Most public {{org.apache.solr.metrics}} classes already have class-level
> javadocs and adding javadocs for the few that don't have them yet could be a
> step towards {{ant precommit}} requiring(\*) javadocs (class-level only, for
> public classes, for org.apache.solr.metrics) selectively on an opt-in basis.
> (\*) = e.g. via {{solr/build.xml}} content like this:
> {code}
> dir="${javadoc.dir}/solr-core/org/apache/solr/metrics" level="class"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13733) add class-level javadocs for public org.apache.solr.metrics classes
Christine Poerschke created SOLR-13733:
--
Summary: add class-level javadocs for public
org.apache.solr.metrics classes
Key: SOLR-13733
URL: https://issues.apache.org/jira/browse/SOLR-13733
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Most public {{org.apache.solr.metrics}} classes already have class-level
javadocs and adding javadocs for the few that don't have them yet could be a
step towards {{ant precommit}} requiring(\*) javadocs (class-level only, for
public classes, for org.apache.solr.metrics) selectively on an opt-in basis.
(\*) = e.g. via {{solr/build.xml}} content like this:
{code}
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8961) CheckIndex: pre-exorcise document id salvage
[
https://issues.apache.org/jira/browse/LUCENE-8961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920917#comment-16920917
]
Christine Poerschke commented on LUCENE-8961:
-
Attached outline work-in-progress patch:
* a new {{-skipCheckIntegrity}} option would allow the tool to proceed past the
initial integrity checks (which would fail e.g. due to footer checksum failure)
* a new {{-idField F}} option would identify the field from which terms are to
be salvaged
* the salvaged terms are currently printed to std.err (and this obviously would
have to be changed somehow)
> CheckIndex: pre-exorcise document id salvage
>
>
> Key: LUCENE-8961
> URL: https://issues.apache.org/jira/browse/LUCENE-8961
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8961.patch
>
>
> The
> [CheckIndex|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java]
> tool supports the exorcising of corrupt segments from an index.
> This ticket proposes to add an extra option which could first be used to
> potentially salvage the document ids of the segment(s) about to be exorcised.
> Re-ingestion for those documents could then be arranged so as to repair the
> data damage caused by the exorcising.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8961) CheckIndex: pre-exorcise document id salvage
[ https://issues.apache.org/jira/browse/LUCENE-8961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated LUCENE-8961: Attachment: LUCENE-8961.patch > CheckIndex: pre-exorcise document id salvage > > > Key: LUCENE-8961 > URL: https://issues.apache.org/jira/browse/LUCENE-8961 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Christine Poerschke >Priority: Minor > Attachments: LUCENE-8961.patch > > > The > [CheckIndex|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java] > tool supports the exorcising of corrupt segments from an index. > This ticket proposes to add an extra option which could first be used to > potentially salvage the document ids of the segment(s) about to be exorcised. > Re-ingestion for those documents could then be arranged so as to repair the > data damage caused by the exorcising. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8961) CheckIndex: pre-exorcise document id salvage
Christine Poerschke created LUCENE-8961: --- Summary: CheckIndex: pre-exorcise document id salvage Key: LUCENE-8961 URL: https://issues.apache.org/jira/browse/LUCENE-8961 Project: Lucene - Core Issue Type: New Feature Reporter: Christine Poerschke The [CheckIndex|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/lucene/core/src/java/org/apache/lucene/index/CheckIndex.java] tool supports the exorcising of corrupt segments from an index. This ticket proposes to add an extra option which could first be used to potentially salvage the document ids of the segment(s) about to be exorcised. Re-ingestion for those documents could then be arranged so as to repair the data damage caused by the exorcising. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13717) Distributed Grouping breaks multi valued 'fl' param
[
https://issues.apache.org/jira/browse/SOLR-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920856#comment-16920856
]
Christine Poerschke commented on SOLR-13717:
Code change looks good to me.
Attached patch has a potential alternative for the test change, using a {{for
(boolean withFL : new boolean[] \{true, false\})}} loop to reduce code
duplication associated with the "special check: same query, but empty fl" test
portion.
> Distributed Grouping breaks multi valued 'fl' param
> ---
>
> Key: SOLR-13717
> URL: https://issues.apache.org/jira/browse/SOLR-13717
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13717.patch, SOLR-13717.patch
>
>
> Co-worker discovered a bug with (distributed) grouping when multiple {{fl}}
> params are specified.
> {{StoredFieldsShardRequestFactory}} has very (old and) brittle code that
> assumes there will be 0 or 1 {{fl}} params in the original request that it
> should inspect to see if it needs to append (via string concat) the uniqueKey
> field onto in order to collate the returned stored fields into their
> respective (grouped) documents -- and then ignores any additional {{fl}}
> params that may exist in the original request when it does so.
> The net result is that only the uniqueKey field and whatever fields _are_
> specified in the first {{fl}} param specified are fetched from each shard and
> ultimately returned.
> The only workaround is to replace multiple {{fl}} params with a single {{fl}}
> param containing a comma seperated list of the requested fields.
>
> Bug is trivial to reproduce with {{bin/solr -e cloud -noprompt}} by comparing
> these requests which should all be equivilent...
> {noformat}
> $ bin/post -c gettingstarted -out yes example/exampledocs/books.csv
> ...
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author,name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "name":["The Black Company"],
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "name":["Foundation"],
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author=name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=id=author=name=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0553573403"}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354"}]
> }}]}}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13717) Distributed Grouping breaks multi valued 'fl' param
[
https://issues.apache.org/jira/browse/SOLR-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13717:
---
Attachment: SOLR-13717.patch
> Distributed Grouping breaks multi valued 'fl' param
> ---
>
> Key: SOLR-13717
> URL: https://issues.apache.org/jira/browse/SOLR-13717
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13717.patch, SOLR-13717.patch
>
>
> Co-worker discovered a bug with (distributed) grouping when multiple {{fl}}
> params are specified.
> {{StoredFieldsShardRequestFactory}} has very (old and) brittle code that
> assumes there will be 0 or 1 {{fl}} params in the original request that it
> should inspect to see if it needs to append (via string concat) the uniqueKey
> field onto in order to collate the returned stored fields into their
> respective (grouped) documents -- and then ignores any additional {{fl}}
> params that may exist in the original request when it does so.
> The net result is that only the uniqueKey field and whatever fields _are_
> specified in the first {{fl}} param specified are fetched from each shard and
> ultimately returned.
> The only workaround is to replace multiple {{fl}} params with a single {{fl}}
> param containing a comma seperated list of the requested fields.
>
> Bug is trivial to reproduce with {{bin/solr -e cloud -noprompt}} by comparing
> these requests which should all be equivilent...
> {noformat}
> $ bin/post -c gettingstarted -out yes example/exampledocs/books.csv
> ...
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author,name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "name":["The Black Company"],
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "name":["Foundation"],
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=author=name,id=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0812521390",
> "author":["Glen Cook"]}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354",
> "author":["Isaac Asimov"]}]
> }}]}}}
> $ curl
> 'http://localhost:8983/solr/gettingstarted/query?omitHeader=true=true=id=author=name=*:*=true=genre_s'
> {
> "grouped":{
> "genre_s":{
> "matches":10,
> "groups":[{
> "groupValue":"fantasy",
> "doclist":{"numFound":8,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"0553573403"}]
> }},
> {
> "groupValue":"scifi",
> "doclist":{"numFound":2,"start":0,"docs":[
> {
> "id":"0553293354"}]
> }}]}}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-6203:
--
Status: Patch Available (was: Open)
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914493#comment-16914493
]
Christine Poerschke commented on SOLR-6203:
---
Hmm, so first I tried to resume work from the
https://github.com/jitka18/lucene-solr/tree/jira/solr-6203 working branch but
struggled with that because since then (May 2017) many things changed,
understandably so, and refactoring changes (e.g. SOLR-10990 and SOLR-13585 and
SOLR-13603) can be helpful for code readability etc. but can be tough to
conflict resolve on git merge etc.
Anyway, so then I've used
https://github.com/apache/lucene-solr/compare/master...jitka18:jira/solr-6203
as a reference and the patch just attached contains, I think, most (but not
all) of the changes e.g. the SolrIndexSearcher change is missing and also the
test changes are not yet transplanted.
With hindsight, perhaps the tests should have been revived first actually *to
determine if and how this is still an issue with the 8.x Solr series* ... ?
PS: Why the switch back from git branch to patch file? Just small personal
preference in part plus we now have a Lucene/Solr QA bot setup which will
automatically provide patch feedback but the bot does not (yet) do the same for
pull requests.
PS PS: As always, any and all input and contributions appreciated here and if
git branches and pull requests instead of patch file attachments are more your
thing then absolutely please do feel free to choose that option.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-6203:
--
Attachment: SOLR-6203.patch
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13711) remove dead sort==null code paths in QueryCommand.java
[ https://issues.apache.org/jira/browse/SOLR-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13711: --- Status: Patch Available (was: Open) > remove dead sort==null code paths in QueryCommand.java > -- > > Key: SOLR-13711 > URL: https://issues.apache.org/jira/browse/SOLR-13711 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Priority: Minor > Attachments: SOLR-13711.patch > > > This ticket proposes to remove 'dead' QueryCommand.java paths associated with > a 'null' sort value. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13711) remove dead sort==null code paths in QueryCommand.java
[ https://issues.apache.org/jira/browse/SOLR-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13711: --- Attachment: SOLR-13711.patch > remove dead sort==null code paths in QueryCommand.java > -- > > Key: SOLR-13711 > URL: https://issues.apache.org/jira/browse/SOLR-13711 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Priority: Minor > Attachments: SOLR-13711.patch > > > This ticket proposes to remove 'dead' QueryCommand.java paths associated with > a 'null' sort value. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913636#comment-16913636
]
Christine Poerschke commented on SOLR-6203:
---
ticket cross-referencing: I tried to return to this ticket here today and in
doing so realised that a little bit of dead code could be removed in
QueryCommand.java (SOLR-13711 created for that) and that this would mildly
simplify the Sort-to-SortSpecs transition (as part of this ticket here) for
that class, as well as making the code a little clearer by removing unreachable
code.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
>Priority: Major
> Attachments: README, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13711) remove dead sort==null code paths in QueryCommand.java
[ https://issues.apache.org/jira/browse/SOLR-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913635#comment-16913635 ] Christine Poerschke commented on SOLR-13711: Looking at the current https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/search/grouping/distributed/command/QueryCommand.java#L97-L103 implementation: * the sort member is final * the QueryCommand constructor is private * the QueryCommand.Builder.build method rejects null sort values. Therefore the sort value cannot be null and the create and result methods can be (slightly) simplified to not consider null-ness. Will attach proposed patch. Reviews, questions, comments, etc. welcome as usual. Thank you. > remove dead sort==null code paths in QueryCommand.java > -- > > Key: SOLR-13711 > URL: https://issues.apache.org/jira/browse/SOLR-13711 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Priority: Minor > > This ticket proposes to remove 'dead' QueryCommand.java paths associated with > a 'null' sort value. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13711) remove dead sort==null code paths in QueryCommand.java
Christine Poerschke created SOLR-13711: -- Summary: remove dead sort==null code paths in QueryCommand.java Key: SOLR-13711 URL: https://issues.apache.org/jira/browse/SOLR-13711 Project: Solr Issue Type: Wish Reporter: Christine Poerschke This ticket proposes to remove 'dead' QueryCommand.java paths associated with a 'null' sort value. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8944) "I am authorized to contribute" wording in the Pull Request Template
[ https://issues.apache.org/jira/browse/LUCENE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913411#comment-16913411 ] Christine Poerschke commented on LUCENE-8944: - Thanks [~janhoy] for your input! bq. Let’s remove the “I’m authorized” box if it is not needed. ... +1 bq. ... Better to err on asking legal an extra time if no one have a link to such official policy. LEGAL-475 ticket opened. > "I am authorized to contribute" wording in the Pull Request Template > > > Key: LUCENE-8944 > URL: https://issues.apache.org/jira/browse/LUCENE-8944 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Christine Poerschke >Priority: Minor > > This ticket is to consider potential revisions to one of the checklist items > in the [pull request > template|https://github.com/apache/lucene-solr/blob/master/.github/PULL_REQUEST_TEMPLATE.md] > -- its current wording is: > bq. \[ \] I am authorized to contribute this code to the ASF and have removed > any code I do not have a license to distribute. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage
[
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910642#comment-16910642
]
Christine Poerschke commented on SOLR-13257:
+1 i.e. ready to merge from my perspective too, thanks.
> Enable replica routing affinity for better cache usage
> --
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
>Reporter: Michael Gibney
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch,
> SOLR-13257.patch
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> For each shard in a distributed request, Solr currently routes each request
> randomly via
> [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
> to a particular replica. In setups with replication factor >1, this normally
> results in a situation where subsequent requests (which one would hope/expect
> to leverage cached results from previous related requests) end up getting
> routed to a replica that hasn't seen any related requests.
> The problem can be replicated by issuing a relatively expensive query (maybe
> containing common terms?). The first request initializes the
> {{queryResultCache}} on the consulted replicas. If replication factor >1 and
> there are a sufficient number of shards, subsequent requests will likely be
> routed to at least one replica that _hasn't_ seen the query before. The
> replicas with uninitialized caches become a bottleneck, and from the client's
> perspective, many subsequent requests appear not to benefit from caching at
> all.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16906293#comment-16906293
]
Christine Poerschke commented on SOLR-13240:
Thanks [~goodman] revising the patch, this time it passed QA (yay!) and I've
gone ahead and pulled out two small separate bits from it into the commit above
(to potentially make for an easier diff on the remaining changes).
So as a next step then I was trying to better understand the {{TestPolicy}}
changes:
* for TestPolicy.testReplicaCountSuggestions just a comment seems sufficient
* for TestPolicy.testNodeLostMultipleReplica it was a bit tricky to understand
first of all what the existing test actually does; with that in mind the
just-attached patch includes two small refactors to surface the sequential
nature of part of the test – would appreciate any thoughts on that.
With the small refactor in place we can more easily see that two sub-tests are
being changed:
* "lets change the policy such that all replicas that were on node1 can now
fit on node2"
* "now lets change the policy such that a node can have 2 shard2 replicas"
Now to the tricky bit. My interpretion of the revised test expectations is that
now then the "a node can have 2 shardX replicas" condition is no longer being
met i.e. previously r3 and r5 were expected to be on node2 but now r3 and r5
are expected on different nodes. So whilst technically speaking the test
passes, the coverage it intended to provide has been lost and so further
adjustments to that sub-test might be needed to preserve the intended coverage.
What do you think?
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
>
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Attachment: SOLR-13240.patch
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
>
[jira] [Commented] (SOLR-12239) Enabling index sorting causes "segment not sorted with indexSort=null"
[
https://issues.apache.org/jira/browse/SOLR-12239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903060#comment-16903060
]
Christine Poerschke commented on SOLR-12239:
Looks like LUCENE-8505 subsequently changed the {{validateIndexSort}} logic
slightly from 8.0 onwards but the issue here remains based on
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L938-L949]
reading i.e. the transition from "no sorting" to "some sorting" is considered
invalid.
I'm curious if some segments being unsorted could perhaps be accommodated
somehow?
> Enabling index sorting causes "segment not sorted with indexSort=null"
> --
>
> Key: SOLR-12239
> URL: https://issues.apache.org/jira/browse/SOLR-12239
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 7.1
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> When index sorting is enabled on an existing collection/index (using
> SortingMergePolicy), the collection reload causes the following exception:
> {code}
> java.util.concurrent.ExecutionException:
> org.apache.solr.common.SolrException: Unable to create core
> [mycoll_shard1_replica_n1]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.solr.core.CoreContainer.lambda$load$14(CoreContainer.java:671)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.solr.common.SolrException: Unable to create core
> [mycoll_shard1_replica_n1]
> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1045)
> at
> org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:642)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Error opening new searcher
> at org.apache.solr.core.SolrCore.(SolrCore.java:989)
> at org.apache.solr.core.SolrCore.(SolrCore.java:844)
> at
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1029)
> ... 7 more
> Caused by: org.apache.solr.common.SolrException: Error opening new searcher
> at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2076)
> at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2196)
> at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1072)
> at org.apache.solr.core.SolrCore.(SolrCore.java:961)
> ... 9 more
> Caused by: org.apache.lucene.index.CorruptIndexException: segment not sorted
> with indexSort=null (resource=_0(7.1.0):C1)
> at
> org.apache.lucene.index.IndexWriter.validateIndexSort(IndexWriter.java:1185)
> at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1108)
> at
> org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:119)
> at
> org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:94)
> at
> org.apache.solr.update.DefaultSolrCoreState.createMainIndexWriter(DefaultSolrCoreState.java:257)
> at
> org.apache.solr.update.DefaultSolrCoreState.getIndexWriter(DefaultSolrCoreState.java:131)
> at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2037)
> ... 12 more
> {code}
> This means that the user actually needs to delete the index segments, reload
> the collection and then re-index. This is bad user experience.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902321#comment-16902321
]
Christine Poerschke commented on SOLR-13240:
bq. ... Sorry for the delay in the reply ...
No worries at all, we all contribute here as and when time permits and
inevitably that will vary. Thanks for returning to this and continuing!
bq. ... Your interpretation seems correct to me also ...
Thanks for the second opinion.
bq. ... _(without approaching it in a way of, lets just change it to what it's
complaining about to make the test pass)_ ...
Indeed, that's very important. :-)
bq. ... What doesn't make sense to me ... If you spot something that I can't
see then let me know. ...
bq. ... SOLR-13240 does not apply to master. Rebase required? Wrong Branch? See
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help.
...
It seems that the latest patch is relative to a different branch (7.4?) and
thus (in this particular case) Lucene/Solr QA cannot apply it. I'm wondering if
the code and/or the tests subsequently changed in a way that would make the
equivalent analysis or interpretation (and test adjustments) for the master
branch easier?
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
>
[jira] [Commented] (SOLR-12230) Deprecate SortingMergePolicy
[ https://issues.apache.org/jira/browse/SOLR-12230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902182#comment-16902182 ] Christine Poerschke commented on SOLR-12230: ticket cross-referencing: there is overlap between SOLR-9108 and SOLR-12230 and SOLR-13681 tickets > Deprecate SortingMergePolicy > > > Key: SOLR-12230 > URL: https://issues.apache.org/jira/browse/SOLR-12230 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-12230.patch > > > The SortingMergePolicy should be deprecated since first class support is now > available (LUCENE-6766). The indexSort configuration can be accepted via the > solrconfig's indexConfig section directly, and SMP can throw a deprecation > warning through the 7x versions of Solr. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9108) Improve how index time sorting is configured
[
https://issues.apache.org/jira/browse/SOLR-9108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902181#comment-16902181
]
Christine Poerschke commented on SOLR-9108:
---
ticket cross-referencing: there is overlap between SOLR-9108 and SOLR-12230 and
SOLR-13681 tickets
> Improve how index time sorting is configured
>
>
> Key: SOLR-9108
> URL: https://issues.apache.org/jira/browse/SOLR-9108
> Project: Solr
> Issue Type: Improvement
>Reporter: Michael McCandless
>Priority: Major
>
> Spinoff from LUCENE-6766.
> We used to have a {{SortingMergePolicy}} to configure index time sorting, but
> with LUCENE-6766 you now set this on {{IndexWriterConfig}}.
> Solr had exposed index time sorting, so to preserve back-compat, I kept
> {{SortingMergePolicy}} alive, moved to solr's sources, but use it simply as a
> holder to pull the index sort from and pass to IWC.
> This preserves back compat, but I think it'd be cleaner going forward to just
> allow index sort to be specified somewhere in {{solrconfig.xml}} wherever
> other index writer settings are set?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13681) make Lucene's index sorting directly configurable in Solr
[
https://issues.apache.org/jira/browse/SOLR-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902180#comment-16902180
]
Christine Poerschke commented on SOLR-13681:
ticket cross-referencing: there is overlap between SOLR-9108 and SOLR-12230 and
SOLR-13681 tickets
(I've chosen to create SOLR-13681 here separately as a potential way of making
the index sorting configurable _separately_ from any sorting merge policy
related changes but I have no immediate plans to work on this much further here
at this time.)
> make Lucene's index sorting directly configurable in Solr
> -
>
> Key: SOLR-13681
> URL: https://issues.apache.org/jira/browse/SOLR-13681
> Project: Solr
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13681.patch
>
>
> History/Background:
> * SOLR-5730 made Lucene's SortingMergePolicy and
> EarlyTerminatingSortingCollector configurable in Solr 6.0 or later.
> * LUCENE-6766 make index sorting a first-class citizen in Lucene 6.2 or later.
> Current status:
> * In Solr 8.2 use of index sorting is only available via configuration of a
> (top-level) merge policy that is a SortingMergePolicy and that policy's sort
> is then passed to the index writer config via the
> {code}
> if (mergePolicy instanceof SortingMergePolicy) {
> Sort indexSort = ((SortingMergePolicy) mergePolicy).getSort();
> iwc.setIndexSort(indexSort);
> }
> {code}
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L241-L244
> code path.
> Proposed change:
> * in-scope for this ticket: To add direct support for index sorting
> configuration in Solr.
> * out-of-scope for this ticket: deprecation and removal of SortingMergePolicy
> support
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13681) make Lucene's index sorting directly configurable in Solr
[
https://issues.apache.org/jira/browse/SOLR-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902179#comment-16902179
]
Christine Poerschke commented on SOLR-13681:
Attached initial partial patch is for an {{indexSort}} element within the
{{indexConfig}} element in {{solrconfig.xml}} configuration.
Illustration:
{code}
timestamp desc
{code}
Related Solr Ref Guide documentation:
* [https://lucene.apache.org/solr/guide/8_1/indexconfig-in-solrconfig.html]
> make Lucene's index sorting directly configurable in Solr
> -
>
> Key: SOLR-13681
> URL: https://issues.apache.org/jira/browse/SOLR-13681
> Project: Solr
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13681.patch
>
>
> History/Background:
> * SOLR-5730 made Lucene's SortingMergePolicy and
> EarlyTerminatingSortingCollector configurable in Solr 6.0 or later.
> * LUCENE-6766 make index sorting a first-class citizen in Lucene 6.2 or later.
> Current status:
> * In Solr 8.2 use of index sorting is only available via configuration of a
> (top-level) merge policy that is a SortingMergePolicy and that policy's sort
> is then passed to the index writer config via the
> {code}
> if (mergePolicy instanceof SortingMergePolicy) {
> Sort indexSort = ((SortingMergePolicy) mergePolicy).getSort();
> iwc.setIndexSort(indexSort);
> }
> {code}
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L241-L244
> code path.
> Proposed change:
> * in-scope for this ticket: To add direct support for index sorting
> configuration in Solr.
> * out-of-scope for this ticket: deprecation and removal of SortingMergePolicy
> support
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13681) make Lucene's index sorting directly configurable in Solr
[
https://issues.apache.org/jira/browse/SOLR-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13681:
---
Attachment: SOLR-13681.patch
> make Lucene's index sorting directly configurable in Solr
> -
>
> Key: SOLR-13681
> URL: https://issues.apache.org/jira/browse/SOLR-13681
> Project: Solr
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13681.patch
>
>
> History/Background:
> * SOLR-5730 made Lucene's SortingMergePolicy and
> EarlyTerminatingSortingCollector configurable in Solr 6.0 or later.
> * LUCENE-6766 make index sorting a first-class citizen in Lucene 6.2 or later.
> Current status:
> * In Solr 8.2 use of index sorting is only available via configuration of a
> (top-level) merge policy that is a SortingMergePolicy and that policy's sort
> is then passed to the index writer config via the
> {code}
> if (mergePolicy instanceof SortingMergePolicy) {
> Sort indexSort = ((SortingMergePolicy) mergePolicy).getSort();
> iwc.setIndexSort(indexSort);
> }
> {code}
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L241-L244
> code path.
> Proposed change:
> * in-scope for this ticket: To add direct support for index sorting
> configuration in Solr.
> * out-of-scope for this ticket: deprecation and removal of SortingMergePolicy
> support
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13681) make Lucene's index sorting directly configurable in Solr
Christine Poerschke created SOLR-13681:
--
Summary: make Lucene's index sorting directly configurable in Solr
Key: SOLR-13681
URL: https://issues.apache.org/jira/browse/SOLR-13681
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
History/Background:
* SOLR-5730 made Lucene's SortingMergePolicy and
EarlyTerminatingSortingCollector configurable in Solr 6.0 or later.
* LUCENE-6766 make index sorting a first-class citizen in Lucene 6.2 or later.
Current status:
* In Solr 8.2 use of index sorting is only available via configuration of a
(top-level) merge policy that is a SortingMergePolicy and that policy's sort is
then passed to the index writer config via the
{code}
if (mergePolicy instanceof SortingMergePolicy) {
Sort indexSort = ((SortingMergePolicy) mergePolicy).getSort();
iwc.setIndexSort(indexSort);
}
{code}
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.2.0/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L241-L244
code path.
Proposed change:
* in-scope for this ticket: To add direct support for index sorting
configuration in Solr.
* out-of-scope for this ticket: deprecation and removal of SortingMergePolicy
support
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900959#comment-16900959
]
Christine Poerschke commented on SOLR-13677:
{code:java}
- public void registerGauge(SolrInfoBean info, String registry, Gauge gauge,
String tag, boolean force, String metricName, String... metricPath) {
+ public GaugeRef registerGauge(SolrInfoBean info, String registry, Gauge
gauge, String tag, boolean force, String metricName, String... metricPath) {
{code}
The above {{registerGauge}} method change to make it return a gauge reference
encourages but does not ensure that the caller 'remembers' the reference and so
that it is later then included in the unregister calls. There's also a small
amount of repetition w.r.t. iterating over the {{myGauges}} collection and
unregistering the elements.
I wonder if some sort of container or wrapper class might be helpful i.e.
{{SolrMetricManager.registerGauge}} would be sure to call 'remember' for the
gauge and the close(\?) method of the producer would call the 'forgetAll'
method. What do you think?
{code:java}
+ class FooBar {
+ private final List gaugeRefs = new ArrayList<>();
+ void remember(GaugeRef gaugeRef) {
+ gaugeRefs.add(gaugeRef);
+ }
+ void forgetAll() {
+ for (GaugeRef gaugeRef : gaugeRefs) {
+ gaugeRef.unregister();
+ }
+ gaugeRefs.clear();
+ }
+ }
+
+ public void registerGauge(FooBar memory, SolrInfoBean info, String registry,
Gauge gauge, String tag, boolean force, String metricName, String...
metricPath) {
+ memory.remember(registerGauge(info, registry, gauge, tag, force,
metricName, metricPath));
+ }
+
+ private GaugeRef registerGauge(SolrInfoBean info, String registry, Gauge
gauge, String tag, boolean force, String metricName, String... metricPath) {
- public void registerGauge(SolrInfoBean info, String registry, Gauge gauge,
String tag, boolean force, String metricName, String... metricPath) {
...
{code}
> All Metrics Gauges should be unregistered by the objects that registered them
> -
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if
> the lifecycle of the object is different from that of the core itself, these
> objects will never be unregistered from the metrics registry. This will lead
> to memory leaks
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage
[
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899135#comment-16899135
]
Christine Poerschke commented on SOLR-13257:
Thanks [~tomasflobbe] for the ping! I left some comments on the pull requests
but have no concerns, it's a very elegant code solution indeed, thank you
[~mgibney] for developing and contributing it.
> Enable replica routing affinity for better cache usage
> --
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
>Reporter: Michael Gibney
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch,
> SOLR-13257.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> For each shard in a distributed request, Solr currently routes each request
> randomly via
> [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
> to a particular replica. In setups with replication factor >1, this normally
> results in a situation where subsequent requests (which one would hope/expect
> to leverage cached results from previous related requests) end up getting
> routed to a replica that hasn't seen any related requests.
> The problem can be replicated by issuing a relatively expensive query (maybe
> containing common terms?). The first request initializes the
> {{queryResultCache}} on the consulted replicas. If replication factor >1 and
> there are a sufficient number of shards, subsequent requests will likely be
> routed to at least one replica that _hasn't_ seen the query before. The
> replicas with uninitialized caches become a bottleneck, and from the client's
> perspective, many subsequent requests appear not to benefit from caching at
> all.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8944) "I am authorized to contribute" wording in the Pull Request Template
[ https://issues.apache.org/jira/browse/LUCENE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899040#comment-16899040 ] Christine Poerschke commented on LUCENE-8944: - Here's some thoughts that occurred to me this week: * "code" could be broadened out to "changes" to include code as well as documentation and test contributions. * "ASF" could be expanded to "Apache Software Foundation" or "Apache Software Foundation (ASF)". * Could we sign-post contributors to with further information that may be helpful in a "I don't know if I'm authorized or not." scenario? * How to provide helpful feedback for pull requests were the "I am authorized" checklist item is unchecked? Is an unchecked checklist item different to a pull request that does not have the checklist or the checklist item? If we accept pull requests without the checklist item then is it perhaps not strictly necessary to have the checklist item? ** I've looked around a little in the Apache documentation and at some other Apache projects' pull request templates but found no obvious answer to this. Perhaps a [Legal Discuss|https://issues.apache.org/jira/projects/LEGAL/issues] issue could be opened but first wanted to ask on a project level here. What do others think? > "I am authorized to contribute" wording in the Pull Request Template > > > Key: LUCENE-8944 > URL: https://issues.apache.org/jira/browse/LUCENE-8944 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Christine Poerschke >Priority: Minor > > This ticket is to consider potential revisions to one of the checklist items > in the [pull request > template|https://github.com/apache/lucene-solr/blob/master/.github/PULL_REQUEST_TEMPLATE.md] > -- its current wording is: > bq. \[ \] I am authorized to contribute this code to the ASF and have removed > any code I do not have a license to distribute. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8944) "I am authorized to contribute" wording in the Pull Request Template
Christine Poerschke created LUCENE-8944: --- Summary: "I am authorized to contribute" wording in the Pull Request Template Key: LUCENE-8944 URL: https://issues.apache.org/jira/browse/LUCENE-8944 Project: Lucene - Core Issue Type: Improvement Reporter: Christine Poerschke This ticket is to consider potential revisions to one of the checklist items in the [pull request template|https://github.com/apache/lucene-solr/blob/master/.github/PULL_REQUEST_TEMPLATE.md] -- its current wording is: bq. \[ \] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13666) Pull Request Template to sign-post to the Solr Ref Guide source
[ https://issues.apache.org/jira/browse/SOLR-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke resolved SOLR-13666. Resolution: Done Assignee: Christine Poerschke Fix Version/s: master (9.0) > Pull Request Template to sign-post to the Solr Ref Guide source > --- > > Key: SOLR-13666 > URL: https://issues.apache.org/jira/browse/SOLR-13666 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897063#comment-16897063
]
Christine Poerschke commented on SOLR-13658:
bq. +1 to prevent use of "var" until Solr 8 is finished. ...
+1 from me too.
On the mechanics of it, is this something that could be done via [~thetaphi]'s
Forbidden APIs mechanism or are we looking at a pattern matching approach in
https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/groovy/check-source-patterns.groovy
or thereabouts?
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13666) Pull Request Template to sign-post to the Solr Ref Guide source
Christine Poerschke created SOLR-13666: -- Summary: Pull Request Template to sign-post to the Solr Ref Guide source Key: SOLR-13666 URL: https://issues.apache.org/jira/browse/SOLR-13666 Project: Solr Issue Type: Wish Reporter: Christine Poerschke -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13585:
---
Resolution: Fixed
Fix Version/s: 8.3
master (9.0)
Status: Resolved (was: Patch Available)
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887998#comment-16887998
]
Christine Poerschke commented on SOLR-13240:
So looking at the
[TestPolicy.testReplicaCountSuggestions|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/solrj/src/test/org/apache/solr/client/solrj/cloud/autoscaling/TestPolicy.java#L2015-L2031]
method, it does a {{loadFromResource}} on
[testReplicaCountSuggestions.json|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/solrj/src/test-files/solrj/solr/autoscaling/testReplicaCountSuggestions.json]
and my interpretation/explanation of the expected test result would be
something like "one of the two cores on 10.0.0.6:8983_solr should move to
10.0.0.6:7574_solr and (everything else being equal) core_node1 is chosen ahead
of core_node2 based on its name".
It might be nice to find and add similar narrative for the
[TestPolicy.testNodeLostMultipleReplica|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/solrj/src/test/org/apache/solr/client/solrj/cloud/autoscaling/TestPolicy.java#L952-L1083]
method too, though its logic is more intricate.
What do you think?
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
>
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885125#comment-16885125
]
Christine Poerschke commented on SOLR-13240:
Thanks [~Goodman] for persevering despite frustrations!
{quote}... I changed this to use SolrTestCaseJ4 and it passed.
{quote}
Interesting. From a quick
[https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/SolrTestCase.java]
vs.
[https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java]
comparison it's not all that apparent to me why use of the latter (derived)
class would be beneficial here, hmm.
Even more mysteriously, for me running your latest patch locally still gives
test failures albeit with a potential pattern:
{code:java}
ant test -Dtestcase=TestPolicy* 2>&1 | grep expected
[junit4]> Throwable #1: org.junit.ComparisonFailure:
expected: but was:
[junit4]> Throwable #1: org.junit.ComparisonFailure: expected: but
was:
[junit4]> Throwable #1: org.junit.ComparisonFailure:
expected: but was:
[junit4]> Throwable #1: org.junit.ComparisonFailure: expected: but
was:
{code}
So it seems that now {{...1}} is the actual outcome but before "something else"
was the actual (and expected). A possible speculation is that the previous test
expectations somehow implicitly relied on the sorting implementation?
Let's see what {{Lucene/Solr QA Jenkins}} comes back with next then.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
>
[jira] [Commented] (LUCENE-8883) CHANGES.txt: Auto add issue categories on new releases
[
https://issues.apache.org/jira/browse/LUCENE-8883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885095#comment-16885095
]
Christine Poerschke commented on LUCENE-8883:
-
Both the script changes and the results of running it locally look alright to
me.
A small optional coding style observation would be that {{is_bugfix}} rather
than {{isBugfix}} might be more consistent with existing naming styles in the
script.
> CHANGES.txt: Auto add issue categories on new releases
> --
>
> Key: LUCENE-8883
> URL: https://issues.apache.org/jira/browse/LUCENE-8883
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE-8883.patch, LUCENE-8883.patch
>
>
> As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some
> sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".
> There is no "Improvements" so no surprise here, the New Features category
> has issues that ought to be listed as such. I think the order vary as well.
> I propose that on new releases, the initial state of the next release in
> CHANGES.txt have these sections. They can easily be removed at the upcoming
> release if there are no such sections, or they could stay as empty. It seems
> addVersion.py is the code that sets this up and it could be enhanced.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884073#comment-16884073
]
Christine Poerschke commented on SOLR-13585:
bq. The patch doesn't appear to include any new or modified tests. Please
justify why no new tests are needed for this patch. Also please list what
manual steps were performed to verify this patch.
* This is a relatively straightforward refactoring change with no
obvious/clear/new/good ROI targets to extend existing test coverage.
* Lucene/Solr QA Jenkins ran the {{core}} tests.
* [~diegoceccarelli] reviewed the patch:
https://github.com/apache/lucene-solr/pull/300/files#r303058934
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884067#comment-16884067
]
Christine Poerschke commented on SOLR-13240:
Hmm, probably something to do with the build dependencies i.e. {{solr/solrj}}
test runs assuming that a compile happened already previously e.g.
{code}
ant clean
ant compile-test
cd solr/solrj
ant test -Dtestcase=TestPolicy*
{code}
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
>
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882820#comment-16882820
]
Christine Poerschke commented on SOLR-13240:
bq. ... Failed junit tests
solr.client.solrj.cloud.autoscaling.TestPolicyOld
solr.client.solrj.cloud.autoscaling.TestPolicy ...
Am able to reproduce via {{cd solr/solrj ; ant test -Dtestcase=TestPolicy*}}
locally. Don't personally have bandwidth at the moment to delve in further but
perhaps someone else would have bandwidth and curiosity to take a look and
revise the patch? Thank you.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
>
[jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage
[
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882405#comment-16882405
]
Christine Poerschke commented on SOLR-13257:
Thanks [~mgibney] for creating and working on this ticket!
I have some "requirements" or "intended behaviour" type questions or thoughts,
perhaps best posed via examples.
1. The out-of-the-box behaviour (in the absence of {{shards.preference}} or
similar parameters) is, as you say, a random choice.
*
** Example: A collection with three replicas (replicaA, replicaB, replicaC),
all of which are available at the time of searching.
** Expected behaviour: The list of available replicas is randomly shuffled
i.e. there are {{3! = 6}} possibilities overall: {{[ [A, B, C], [A, C, B], [B,
A, C], [B, C, A], [C, A, B], [C, B, A] ]}}
2. The objective of this ticket i.e. the proposed behaviour (in the absence of
{{shards.preference}} or similar parameters) is reduce or remove the
random-ness of the out-of-the-box behaviour.
*
** Example: A collection with three replicas (replicaA, replicaB, replicaC),
all of which are available at the time of searching. The request indicates
(directly via a numeric value parameter or indirectly via a non-numeric value
parameter that can be hashed) the affinity to an element in or a portion of the
list of replicas. Let's assume the affinity expressed translates into replica
{{A}}.
** Expected behaviour:
*** Possibility 1: The preferred replica is {{A}} but beyond the first choice
the random-ness remains for load balancing purposes i.e. there are {{2! = 2}}
possibilities overall: {{[ [A, B, C], [A, C, B] ]}}
*** Possibility 2: The preferred replica is {{A}} and also beyond that first
choice there is no random-ness i.e. the replica list is sorted
deterministically to give just one possibility: {{[A, B, C]}}
3. The existing {{shards.preference}} parameter influences the replica choices
(in the absence of new affinity logic).
(caveat: I presume the below is the existing behaviour of the existing code but
have not recently read the code in detail to fully convince myself that this is
so.)
*
** Example 1: A collection with six replicas spread equally across three
locations. The request indicates a preference for "Europe" location.
** Expected behaviour: The preferred replicas (based on location) are at the
start of the list and the not-preferred replicas are at the end of the list.
The ordering within the start and end portions of the list is random giving
{{2! * 4! = 2*1 * 4*3*2*1 = 2 * 24 = 48}} possibilities overall.
*
** Example 2: A collection with six replicas spread equally across three
locations and the two replicas at each location are of different types e.g.
{{PULL}} and {{TLOG}}. The request indicates a preference primarily for
"Europe" location and secondarily for "PULL" type.
** Expected behaviour: The preferred replicas (based on location) are at the
start of the list and the not-preferred replicas are at the end of the list.
The ordering within the start portion of the list becomes deterministic via the
secondary preference (e.g. {{[ replicaB1(europe,pull), replicaB2(europe,tlog)
]}}) and the ordering within the end portion of the list is narrowed down via
the secondary preference but some random-ness remains giving 4 possibilities
overall:
{code:java}
[ replicaB1(europe,pull), replicaB2(europe,tlog),
replicaA1(america,pull), replicaC1(asia,pull),
replicaA2(america,tlog), replicaC2(asia,tlog) ]
[ replicaB1(europe,pull), replicaB2(europe,tlog),
replicaA1(america,pull), replicaC1(asia,pull),
replicaC2(asia,tlog), replicaA2(america,tlog) ]
[ replicaB1(europe,pull), replicaB2(europe,tlog),
replicaC1(asia,pull), replicaA1(america,pull),
replicaC2(asia,tlog), replicaA2(america,tlog) ]
[ replicaB1(europe,pull), replicaB2(europe,tlog),
replicaC1(asia,pull), replicaA1(america,pull),
replicaA2(america,tlog), replicaC2(asia,tlog) ]
{code}
4. The new shard affinity logic combined with a single {{shards.preference}}
parameter.
*
** Example: A collection with six replicas spread equally across three
locations. The request indicates a preference for "Europe" location.
** Expected behaviour: The preferred replicas (based on location) are at the
start of the list and the not-preferred replicas are at the end of the list.
*** The ordering within the "Europe" start portion of the list becomes
deterministic via the new shard affinity logic.
*** Does the new shard affinity logic influence the ordering within the end
portion of the list too?
5. The new shard affinity logic combined with multiple {{shards.preference}}
parameters.
*
** At its simplest each {{shards.preference}} parameter will have two choices
e.g. "PULL" vs. "TLOG" replica type or "Europe" vs. unknown replica location.
** Assuming two {{shards.preference}} parameters with two choices each the
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881977#comment-16881977
]
Christine Poerschke commented on SOLR-13240:
bq. ... Validate source patterns validate-source-patterns failed ...
This was a case of {{"Solr test cases should extend SolrTestCase rather than
LuceneTestCase"}} which I missed, oops. Just attached patch also removes two
imports that are no longer needed now that the {{MoveReplicaSuggesterTest}}
extends a base class.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
>
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Attachment: SOLR-13240.patch
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
[jira] [Comment Edited] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881150#comment-16881150
]
Christine Poerschke edited comment on SOLR-13240 at 7/9/19 11:37 AM:
-
bq. ... As for attribution, "Richard Goodman" is fine. Tim also helped on this,
if he isn't included as well ...
Great, thanks for clarifying! Yes, customarily attribution would be for both of
you, of course. And [~HendrikH] too of course for issue creation and diagnosing
here.
Next step here will be for {{Lucene/Solr QA}} Jenkins to add feedback to the
ticket here -- https://builds.apache.org/job/PreCommit-SOLR-Build/ -- that
should happen automatically.
was (Author: cpoerschke):
bq. ... As for attribution, "Richard Goodman" is fine. Tim also helped on this,
if he isn't included as well ...
Great, thanks for clarifying! Yes, customarily attribution would be for both of
you, of course.
Next step here will be for {{Lucene/Solr QA}} Jenkins to add feedback to the
ticket here -- https://builds.apache.org/job/PreCommit-SOLR-Build/ -- that
should happen automatically.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
>
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881150#comment-16881150
]
Christine Poerschke commented on SOLR-13240:
bq. ... As for attribution, "Richard Goodman" is fine. Tim also helped on this,
if he isn't included as well ...
Great, thanks for clarifying! Yes, customarily attribution would be for both of
you, of course.
Next step here will be for {{Lucene/Solr QA}} Jenkins to add feedback to the
ticket here -- https://builds.apache.org/job/PreCommit-SOLR-Build/ -- that
should happen automatically.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
>
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881144#comment-16881144
]
Christine Poerschke commented on SOLR-13240:
{quote}... I've attached a patch that myself and [~TimOwen] worked on. ...
{quote}
[~Goodman] - do you have any preference as to {{solr/CHANGES.txt}} attribution
choice of name for yourself e.g. "Richard" (JIRA full name) or "Goodman" (JIRA
Username) or a variant of the two or something else perhaps? It's your choice,
I'm just looking ahead here a little towards patch commit time. Thanks!
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
>
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881139#comment-16881139
]
Christine Poerschke commented on SOLR-13240:
Attached revised patch with {{MoveReplicaSuggesterTest}} suggested changes (no
pun intended) as follows:
* remove one unused import (to make {{ant precommit}} pass)
* add two more asserts to {{assertLeaderProperties}}
* move the test from {{solr/core}} to {{solr/solrj}} since
{{MoveReplicaSuggester}} itself lives in the latter
* increase test coverage via the use of randomisation
**
https://berlinbuzzwords.de/14/session/randomize-your-tests-and-it-will-blow-your-socks
might be of interest in this context
** {{cd solr/solrj ; ant beast -Dbeast.iters=10
-Dtestcase=MoveReplicaSuggesterTest}} can be used to run the test multiple times
How does that sound?
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
>
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Attachment: SOLR-13240.patch
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
>
[jira] [Commented] (SOLR-13609) Ability to know when an expunge has finished
[ https://issues.apache.org/jira/browse/SOLR-13609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879412#comment-16879412 ] Christine Poerschke commented on SOLR-13609: Some of the [https://lucene.apache.org/solr/guide/8_1/metrics-reporting.html#index-merge-metrics] metrics look like they might also provide the kind of visibility you are looking for, though presumably the metrics would not differentiate between any merges that you explicitly initiated and any merges that are occurring 'naturally'. > Ability to know when an expunge has finished > > > Key: SOLR-13609 > URL: https://issues.apache.org/jira/browse/SOLR-13609 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.4 >Reporter: Richard >Priority: Major > > At the company I work for, we do nightly expunges to clear down deleted docs > _(providing the threshold is above 5% in our case)_. > Whilst this has been okay for us, we want the ability to know when an expunge > has completed. At the moment we do some calculations to estimate how long it > would take. > it would be nice if there was a way to see when an expunge has completed. > This could either be by assigning an async id to the call, or any other means > of having visibility. > I started to look into this issue, but saw that the underlying call for > expunging starts to use the lucene side of the code base, so thought I was > digging to deep, so any advice on this issue would be much appreciated _(as > I'm trying to contribute more to OOS)_. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Component/s: AutoScaling
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
>
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Status: Patch Available (was: Open)
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>
>
[jira] [Created] (SOLR-13611) deprecated vs. replacement elements
Christine Poerschke created SOLR-13611:
--
Summary: deprecated vs. replacement
elements
Key: SOLR-13611
URL: https://issues.apache.org/jira/browse/SOLR-13611
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
In
[SolrXmlConfig.fromConfig|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.0/solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java#L73-L97]
the {{deprecatedUpdateConfig}} naming and usage suggests that some
{{}} elements e.g. {{distribUpdateSoTimeout}} are deprecated in
favour of a {{}} element with the same name.
The
[solr.xml|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.0/solr/server/solr/solr.xml]
included in our releases and the
[documentation|https://lucene.apache.org/solr/guide/8_1/format-of-solr-xml.html]
still use what would then appear to be the deprecated of the two choices and
as far as I can tell no warnings about this are logged on Solr startup.
This ticket here is to start a pathway via which support for the deprecated
choice would eventually be removed e.g. future 8.x releases could WARN if the
deprecated choice is used and then in 9.x releases support would be removed and
an exception thrown if the deprecated choice is still encountered in a
{{solr.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13610) document more solr.xml elements
Christine Poerschke created SOLR-13610: -- Summary: document more solr.xml elements Key: SOLR-13610 URL: https://issues.apache.org/jira/browse/SOLR-13610 Project: Solr Issue Type: Wish Reporter: Christine Poerschke It appears that not all of the elements used in [SolrXmlConfig.loadUpdateConfig|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.0/solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java#L292-L351] are currently documented on the [Format of solr.xml|https://lucene.apache.org/solr/guide/8_1/format-of-solr-xml.html] page e.g. the following four elements are currently undocumented: * maxUpdateConnections * maxUpdateConnectionsPerHost * metricNameStrategy * maxRecoveryThreads This ticket here is to update https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/format-of-solr-xml.adoc to document more elements. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13585:
---
Status: Patch Available (was: Open)
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875173#comment-16875173
]
Christine Poerschke edited comment on SOLR-13585 at 6/28/19 7:41 PM:
-
In the context of SOLR-11831 (and assuming separate subsequent small
private-to-protected and Array-or-List-to-Object style tweaks) the factored out
methods would also help avoid code duplication:
* [https://github.com/apache/lucene-solr/pull/300/files#r275043339]
*
[https://github.com/cpoerschke/lucene-solr/commit/10fbfd1dcf16065688c3610b26a55f2aa9c99f8a]
*
[https://github.com/apache/lucene-solr/commit/9480482166b05d04eb2bb55227baf4f3c6549ab9]
* [https://github.com/apache/lucene-solr/pull/300/files#r288569478]
*
[https://github.com/apache/lucene-solr/commit/0eb206bf6f635ba2e7514efa369e09137911b825]
* [https://github.com/apache/lucene-solr/pull/300/files#r298725095]
At this point it might be helpful to briefly outline the difference between the
existing {{SearchGroupsResultTransformer}} and SOLR-11831's proposed and
tentatively named {{SkipSecondStepSearchResultResultTransformer}} class i.e.
what is different between them but why can they still share code:
* The {{SearchGroupsResultTransformer}} transforms search groups i.e. it needs
to know the identity of the group and a sort value for it so that groups from
multiple shards can be collated correctly. In this first phase there is no need
to know the identity of documents in each group since those are determined in
the second phase.
* The {{SkipSecondStepSearchResultResultTransformer}} needs to know everything
that the {{SearchGroupsResultTransformer}} needs to know but if the second
phase is to be skipped (in certain circumstances) then in the first phase there
is a need to know the identity of documents in each group (technically just one
document per group i.e. SOLR-11831 requires group.limit=1).
* In terms of serialisation and deserialisation of search groups therefore the
{{SkipSecondStepSearchResultResultTransformer}} can use the same code as the
{{SearchGroupsResultTransformer}} but there is some extra "add-on" info i.e.
the document identity info that needs to be packed (serialised) and unpacked
(deserialised).
was (Author: cpoerschke):
In the context of SOLR-11831 (and assuming separate subsequent small
{{private}}-->{{protected}} and {{...}}-->{{Object}} tweaks) the factored out
methods would also help avoid code duplication:
* [https://github.com/apache/lucene-solr/pull/300/files#r275043339]
*
[https://github.com/cpoerschke/lucene-solr/commit/10fbfd1dcf16065688c3610b26a55f2aa9c99f8a]
*
[https://github.com/apache/lucene-solr/commit/9480482166b05d04eb2bb55227baf4f3c6549ab9]
* [https://github.com/apache/lucene-solr/pull/300/files#r288569478]
*
[https://github.com/apache/lucene-solr/commit/0eb206bf6f635ba2e7514efa369e09137911b825]
* (add-one-more-link-here-shortly)
At this point it might be helpful to briefly outline the difference between the
existing {{SearchGroupsResultTransformer}} and SOLR-11831's proposed and
tentatively named {{SkipSecondStepSearchResultResultTransformer}} class i.e.
what is different between them but why can they still share code:
* The {{SearchGroupsResultTransformer}} transforms search groups i.e. it needs
to know the identity of the group and a sort value for it so that groups from
multiple shards can be collated correctly. In this first phase there is no need
to know the identity of documents in each group since those are determined in
the second phase.
* The {{SkipSecondStepSearchResultResultTransformer}} needs to know everything
that the {{SearchGroupsResultTransformer}} needs to know but if the second
phase is to be skipped (in certain circumstances) then in the first phase there
is a need to know the identity of documents in each group (technically just one
document per group i.e. SOLR-11831 requires group.limit=1).
* In terms of serialisation and deserialisation of search groups therefore the
{{SkipSecondStepSearchResultResultTransformer}} can use the same code as the
{{SearchGroupsResultTransformer}} but there is some extra "add-on" info i.e.
the document identity info that needs to be packed (serialised) and unpacked
(deserialised).
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
>
[jira] [Commented] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875175#comment-16875175
]
Christine Poerschke commented on SOLR-13585:
"factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
(Christine Poerschke, Diego Ceccarelli)" patch attached.
Reviews, comments, questions, etc. welcome as usual, thank you.
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13585:
---
Attachment: SOLR-13585.patch
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13585.patch
>
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875173#comment-16875173
]
Christine Poerschke commented on SOLR-13585:
In the context of SOLR-11831 (and assuming separate subsequent small
{{private}}-->{{protected}} and {{...}}-->{{Object}} tweaks) the factored out
methods would also help avoid code duplication:
* [https://github.com/apache/lucene-solr/pull/300/files#r275043339]
*
[https://github.com/cpoerschke/lucene-solr/commit/10fbfd1dcf16065688c3610b26a55f2aa9c99f8a]
*
[https://github.com/apache/lucene-solr/commit/9480482166b05d04eb2bb55227baf4f3c6549ab9]
* [https://github.com/apache/lucene-solr/pull/300/files#r288569478]
*
[https://github.com/apache/lucene-solr/commit/0eb206bf6f635ba2e7514efa369e09137911b825]
* (add-one-more-link-here-shortly)
At this point it might be helpful to briefly outline the difference between the
existing {{SearchGroupsResultTransformer}} and SOLR-11831's proposed and
tentatively named {{SkipSecondStepSearchResultResultTransformer}} class i.e.
what is different between them but why can they still share code:
* The {{SearchGroupsResultTransformer}} transforms search groups i.e. it needs
to know the identity of the group and a sort value for it so that groups from
multiple shards can be collated correctly. In this first phase there is no need
to know the identity of documents in each group since those are determined in
the second phase.
* The {{SkipSecondStepSearchResultResultTransformer}} needs to know everything
that the {{SearchGroupsResultTransformer}} needs to know but if the second
phase is to be skipped (in certain circumstances) then in the first phase there
is a need to know the identity of documents in each group (technically just one
document per group i.e. SOLR-11831 requires group.limit=1).
* In terms of serialisation and deserialisation of search groups therefore the
{{SkipSecondStepSearchResultResultTransformer}} can use the same code as the
{{SearchGroupsResultTransformer}} but there is some extra "add-on" info i.e.
the document identity info that needs to be packed (serialised) and unpacked
(deserialised).
> factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
>
>
> Key: SOLR-13585
> URL: https://issues.apache.org/jira/browse/SOLR-13585
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
> [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
> and {{transformToNative}} e.g.
> [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
> do quite a few things and factoring out of portions of the code e.g.
> [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
> and
> [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
> could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
Christine Poerschke created SOLR-13585:
--
Summary: factor out
SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
Key: SOLR-13585
URL: https://issues.apache.org/jira/browse/SOLR-13585
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g.
[#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127]
and {{transformToNative}} e.g.
[#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108]
do quite a few things and factoring out of portions of the code e.g.
[#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120]
and
[#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99]
could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13280) strengthen ScheduledTrigger's preferredOperation parameter validation
[
https://issues.apache.org/jira/browse/SOLR-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-13280.
Resolution: Fixed
Fix Version/s: 8.2
master (9.0)
> strengthen ScheduledTrigger's preferredOperation parameter validation
> -
>
> Key: SOLR-13280
> URL: https://issues.apache.org/jira/browse/SOLR-13280
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13280.patch
>
>
> Currently a typo such as (say) {{MOVE_REPLICA}} instead of the correct
> {{MOVEREPLICA}} results in a "success" response for the "set-trigger" call
> but in the Solr logs NullPointerException stuff is happening e.g.
> {code}
> "eventType":"SCHEDULED",
> "properties":{
> "actualEventTime":...,
> "preferredOperation":"MOVE_REPLICA",
> "_enqueue_time_":...}}
> at
> org.apache.solr.cloud.autoscaling.ComputePlanAction.process(ComputePlanAction.java:160)
> ~[?:?]
> at
> org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$null$3(ScheduledTriggers.java:324)
> ~[?:?]
> ... 6 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.getSuggester(Policy.java:628)
> ~[?:?]
> at
> org.apache.solr.cloud.autoscaling.ComputePlanAction.getSuggester(ComputePlanAction.java:262)
> ~[?:?]
> at
> org.apache.solr.cloud.autoscaling.ComputePlanAction.process(ComputePlanAction.java:97)
> ~[?:?]
> at
> org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$null$3(ScheduledTriggers.java:324)
> ~[?:?]
> ... 6 more
> {code}
> Proposed patch to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13576:
---
Resolution: Fixed
Fix Version/s: 8.2
master (9.0)
Status: Resolved (was: Patch Available)
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13279) clarify ScheduledTrigger's "every parameter missing" error response
[
https://issues.apache.org/jira/browse/SOLR-13279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-13279.
Resolution: Fixed
Fix Version/s: 8.2
master (9.0)
> clarify ScheduledTrigger's "every parameter missing" error response
> ---
>
> Key: SOLR-13279
> URL: https://issues.apache.org/jira/browse/SOLR-13279
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13279.patch
>
>
> current behaviour:
> {code}
> "Error validating trigger config scheduled_event_trigger:
> org.apache.solr.common.SolrException: Invalid Date Math
> String:'2019-02-27T20:20:20.202Znull'"
> {code}
> proposed behaviour:
> {code}
> "Error validating trigger config scheduled_event_trigger:
> TriggerValidationException{name=scheduled_event_trigger,
> details='{every=missing required property}'}"
> {code}
> one-line (proposed) patch summary:
> * in the {{ScheduledTrigger}} constructor move {{"every"}} from the
> {{TriggerUtils.validProperties}} to the {{TriggerUtils.requiredProperties}}
> line/list
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875095#comment-16875095
]
Christine Poerschke commented on SOLR-13576:
{quote}The patch doesn't appear to include any new or modified tests. Please
justify why no new tests are needed for this patch. Also please list what
manual steps were performed to verify this patch.
{quote} * This is a straightforward 2-ish-lines factoring out change. No
obvious, clear, new, good ROI targets to extend existing test coverage.
* Lucene/Solr QA Jenkins ran the {{core}} tests.
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13576:
---
Status: Patch Available (was: Open)
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872273#comment-16872273
]
Christine Poerschke commented on SOLR-13576:
"factor out a TopGroupsShardResponseProcessor.fillResultIds method (Christine
Poerschke, Diego Ceccarelli)" patch attached. Will commit in a couple of days
if no questions or concerns.
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13576:
---
Attachment: SOLR-13576.patch
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13576.patch
>
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
[
https://issues.apache.org/jira/browse/SOLR-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872272#comment-16872272
]
Christine Poerschke commented on SOLR-13576:
In the context of SOLR-11831 the method (if it has package visibility) would
also help avoid code duplication:
* https://github.com/apache/lucene-solr/pull/300#discussion_r276714459
*
https://github.com/cpoerschke/lucene-solr/commit/1570f7c0ad0194681897403613e87cfad367d577
* https://github.com/apache/lucene-solr/pull/300#discussion_r290346022
*
https://github.com/apache/lucene-solr/commit/a7df0c0d8d9c292998df1e12848735eaa662ff38
> factor out a TopGroupsShardResponseProcessor.fillResultIds method
> -
>
> Key: SOLR-13576
> URL: https://issues.apache.org/jira/browse/SOLR-13576
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> The {{TopGroupsShardResponseProcessor.process}} method e.g.
> [#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
> does quite a few things and factoring out a {{fillResultIds}} (or similarly
> named) method for the logically distinct
> [#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
> portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13576) factor out a TopGroupsShardResponseProcessor.fillResultIds method
Christine Poerschke created SOLR-13576:
--
Summary: factor out a
TopGroupsShardResponseProcessor.fillResultIds method
Key: SOLR-13576
URL: https://issues.apache.org/jira/browse/SOLR-13576
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
The {{TopGroupsShardResponseProcessor.process}} method e.g.
[#L54-L215|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L54-L215]
does quite a few things and factoring out a {{fillResultIds}} (or similarly
named) method for the logically distinct
[#L192-L214|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L192-L214]
portion could help with code comprehension.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13569) AdminUI visual indication of prod/test/dev environment
[
https://issues.apache.org/jira/browse/SOLR-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16872238#comment-16872238
]
Christine Poerschke commented on SOLR-13569:
I like the idea of visually differentiating clusters.
A question about the
{{-Dsolr.environment=test;label=Functional_test;color=brown}} example in the
{{solr.in.sh}} file: does the choice of semi-colon as a delimiter give rise to
{code}
-Dsolr.environment=test
{code}
vs.
{code}
-Dsolr.environment=test;label=Functional_test;color=brown
{code}
vs.
{code}
-Dsolr.environment="test;label=Functional_test;color=brown"
{code}
or
{code}
-Dsolr.environment=test\;label=Functional_test\;color=brown
{code}
subtlety i.e. if only the environment is specified then that is that but if
label and/or color is specified too then quoting or escaping of the semi-colon
would be required, for the {{solr.in.sh}} file at least; not sure what
equivalent in the {{solr.in.cmd}} file would be?
> AdminUI visual indication of prod/test/dev environment
> --
>
> Key: SOLR-13569
> URL: https://issues.apache.org/jira/browse/SOLR-13569
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: Environment-hint.png, prod-example.png, test-example.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To guard against accidentally changing the wrong cluster, we should add a
> visual indication in the Admin UI of whether you currently work with a
> production environment or not, e.g. a red bar on top with an optional
> environment label, see sketch. The bar could by default be red for
> production, yellow for test and green for dev.
> !Environment-hint.png|width=700!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8743) lucene/queryparser DOMUtils.getAttributeOrFail(Element,String) never fails
[
https://issues.apache.org/jira/browse/LUCENE-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated LUCENE-8743:
Status: Patch Available (was: Open)
> lucene/queryparser DOMUtils.getAttributeOrFail(Element,String) never fails
> --
>
> Key: LUCENE-8743
> URL: https://issues.apache.org/jira/browse/LUCENE-8743
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8743.patch
>
>
> https://docs.oracle.com/javase/8/docs/api/org/w3c/dom/Element.html#getAttribute-java.lang.String-
> describes the {{Element.getAttribute}} return value as "The Attr value as a
> string, or the empty string if that attribute does not have a specified or
> default value." but {{DOMUtils.getAttributeOrFail}} only checks for {{null}}
> and so it never fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7090) Cross collection join
[ https://issues.apache.org/jira/browse/SOLR-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864000#comment-16864000 ] Christine Poerschke commented on SOLR-7090: --- bq. ... we've got two cache regenerators with identical implementations: SolrPluginUtils.IdentityRegenerator (currently showing as unused) and NoOpRegenerator. ... The two regenerators were mentioned above. Just cross-referencing here to say that the former is removed by SOLR-13515 ticket. > Cross collection join > - > > Key: SOLR-7090 > URL: https://issues.apache.org/jira/browse/SOLR-7090 > Project: Solr > Issue Type: New Feature >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 5.2, 6.0 > > Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch > > > Although SOLR-4905 supports joins across collections in Cloud mode, there are > limitations, (i) the secondary collection must be replicated at each node > where the primary collection has a replica, (ii) the secondary collection > must be singly sharded. > This issue explores ideas/possibilities of cross collection joins, even > across nodes. This will be helpful for users who wish to maintain boosts or > signals in a secondary, more frequently updated collection, and perform query > time join of these boosts/signals with results from the primary collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13515) remove SolrPluginUtils.IdentityRegenerator
[
https://issues.apache.org/jira/browse/SOLR-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-13515.
Resolution: Fixed
Fix Version/s: 8.2
master (9.0)
> remove SolrPluginUtils.IdentityRegenerator
> --
>
> Key: SOLR-13515
> URL: https://issues.apache.org/jira/browse/SOLR-13515
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.2
>
>
> {{SolrPluginUtils.IdentityRegenerator}} seems to be identical (no pun
> intended) to {{NoOpRegenerator}}. This ticket proposes to deprecate
> IdentityRegenerator on branch_8x and then remove it on master branch.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L977-L997
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/NoOpRegenerator.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override
[ https://issues.apache.org/jira/browse/SOLR-13511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke resolved SOLR-13511. Resolution: Fixed Fix Version/s: 8.2 master (9.0) > For SearchHandler, expose "new ResponseBuilder()" to allow override > --- > > Key: SOLR-13511 > URL: https://issues.apache.org/jira/browse/SOLR-13511 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Ramsey Haddad >Assignee: Christine Poerschke >Priority: Trivial > Labels: easyfix > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13511.patch, SOLR-13511.patch, SOLR-13511.patch > > > This change is all we want upstream. To use this from our plugins, we intend: > Extend ResponseBuilder to have additional state (and we think others might > want to as well). > Use an extended SearchHandler that simply creates our ResponseBuilder instead > of the standard one. > We also extend QueryComponent to do our extra behavior if it sees our > Response builder instead of the standard one. > We then change config to use our Search Handler for requestHandler with > name="/select" and our QueryComponent for searchComponent with name="query". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13515) remove SolrPluginUtils.IdentityRegenerator
[
https://issues.apache.org/jira/browse/SOLR-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13515:
---
Summary: remove SolrPluginUtils.IdentityRegenerator (was:
deprecate-then-remove SolrPluginUtils.IdentityRegenerator)
> remove SolrPluginUtils.IdentityRegenerator
> --
>
> Key: SOLR-13515
> URL: https://issues.apache.org/jira/browse/SOLR-13515
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> {{SolrPluginUtils.IdentityRegenerator}} seems to be identical (no pun
> intended) to {{NoOpRegenerator}}. This ticket proposes to deprecate
> IdentityRegenerator on branch_8x and then remove it on master branch.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L977-L997
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/NoOpRegenerator.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override
[ https://issues.apache.org/jira/browse/SOLR-13511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13511: --- Attachment: SOLR-13511.patch > For SearchHandler, expose "new ResponseBuilder()" to allow override > --- > > Key: SOLR-13511 > URL: https://issues.apache.org/jira/browse/SOLR-13511 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Reporter: Ramsey Haddad >Assignee: Christine Poerschke >Priority: Trivial > Labels: easyfix > Attachments: SOLR-13511.patch, SOLR-13511.patch, SOLR-13511.patch > > > This change is all we want upstream. To use this from our plugins, we intend: > Extend ResponseBuilder to have additional state (and we think others might > want to as well). > Use an extended SearchHandler that simply creates our ResponseBuilder instead > of the standard one. > We also extend QueryComponent to do our extra behavior if it sees our > Response builder instead of the standard one. > We then change config to use our Search Handler for requestHandler with > name="/select" and our QueryComponent for searchComponent with name="query". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override
[
https://issues.apache.org/jira/browse/SOLR-13511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858879#comment-16858879
]
Christine Poerschke commented on SOLR-13511:
Thanks [~rwhaddad] for opening this ticket!
So the use case, as you already mentioned, is for Solr plugin authors to be
able to main per-request state for their plugin in a custom
[ResponseBuilder|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/ResponseBuilder.java]
class.
* code snippets
{code}
package com.mycompany.myteam.solr;
public class CustomSearchHandler extends
org.apache.solr.handler.component.SearchHandler {
@Override
protected ResponseBuilder newResponseBuilder(SolrQueryRequest req,
SolrQueryResponse rsp, List components) {
return new CustomResponseBuilder(req, rsp, components);
}
}
public class CustomResponseBuilder extends
org.apache.solr.handler.component.ResponseBuilder
{
private FooBar fooBar;
public void setFooBar(FooBar fooBar) { this.fooBar = fooBar; }
public FooBar getFooBar() { return this.fooBar; }
public CustomResponseBuilder(SolrQueryRequest req, SolrQueryResponse rsp,
List components) {
super(req, rsp, components);
}
}
public class CustomQueryComponent extends
org.apache.solr.handler.component.QueryComponent {
...
@Override
public void process(ResponseBuilder rb) throws IOException {
super.process(rb);
if (rb instanceof CustomResponseBuilder) {
CustomResponseBuilder crb = (CustomResponseBuilder)rb;
...
crb.setFooBar(...);
...
}
}
...
}
{code}
* solrconfig.xml snippet:
{code}
customQuery
{code}
Latest attached patch includes javadocs for the new method. If there are no
objections, concerns, questions, etc. then I'll aim to commit the change middle
of next week or so.
> For SearchHandler, expose "new ResponseBuilder()" to allow override
> ---
>
> Key: SOLR-13511
> URL: https://issues.apache.org/jira/browse/SOLR-13511
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Ramsey Haddad
>Priority: Trivial
> Labels: easyfix
> Attachments: SOLR-13511.patch, SOLR-13511.patch
>
>
> This change is all we want upstream. To use this from our plugins, we intend:
> Extend ResponseBuilder to have additional state (and we think others might
> want to as well).
> Use an extended SearchHandler that simply creates our ResponseBuilder instead
> of the standard one.
> We also extend QueryComponent to do our extra behavior if it sees our
> Response builder instead of the standard one.
> We then change config to use our Search Handler for requestHandler with
> name="/select" and our QueryComponent for searchComponent with name="query".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override
[ https://issues.apache.org/jira/browse/SOLR-13511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke reassigned SOLR-13511: -- Assignee: Christine Poerschke > For SearchHandler, expose "new ResponseBuilder()" to allow override > --- > > Key: SOLR-13511 > URL: https://issues.apache.org/jira/browse/SOLR-13511 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Reporter: Ramsey Haddad >Assignee: Christine Poerschke >Priority: Trivial > Labels: easyfix > Attachments: SOLR-13511.patch, SOLR-13511.patch > > > This change is all we want upstream. To use this from our plugins, we intend: > Extend ResponseBuilder to have additional state (and we think others might > want to as well). > Use an extended SearchHandler that simply creates our ResponseBuilder instead > of the standard one. > We also extend QueryComponent to do our extra behavior if it sees our > Response builder instead of the standard one. > We then change config to use our Search Handler for requestHandler with > name="/select" and our QueryComponent for searchComponent with name="query". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13511) For SearchHandler, expose "new ResponseBuilder()" to allow override
[ https://issues.apache.org/jira/browse/SOLR-13511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13511: --- Attachment: SOLR-13511.patch > For SearchHandler, expose "new ResponseBuilder()" to allow override > --- > > Key: SOLR-13511 > URL: https://issues.apache.org/jira/browse/SOLR-13511 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Reporter: Ramsey Haddad >Priority: Trivial > Labels: easyfix > Attachments: SOLR-13511.patch, SOLR-13511.patch > > > This change is all we want upstream. To use this from our plugins, we intend: > Extend ResponseBuilder to have additional state (and we think others might > want to as well). > Use an extended SearchHandler that simply creates our ResponseBuilder instead > of the standard one. > We also extend QueryComponent to do our extra behavior if it sees our > Response builder instead of the standard one. > We then change config to use our Search Handler for requestHandler with > name="/select" and our QueryComponent for searchComponent with name="query". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13496) NullPointerException in JSONWriter.writeSolrDocument
[
https://issues.apache.org/jira/browse/SOLR-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13496:
---
Attachment: SOLR-13496.patch
> NullPointerException in JSONWriter.writeSolrDocument
>
>
> Key: SOLR-13496
> URL: https://issues.apache.org/jira/browse/SOLR-13496
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13496.patch, SOLR-13496.patch, SOLR-13496.patch
>
>
> For non-grouped searches
> [QueryComponent.regularFinishStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L647-L655]
> already considers the possibility of null {{SolrDocument}} values due to an
> index change.
> For grouped searches
> [GroupedEndResultTransformer.transform|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/endresulttransformer/GroupedEndResultTransformer.java#L94-L114]
> potentially adds a null element to a {{SolrDocumentList}}.
> The
> [TextResponseWriter.writeSolrDocumentList|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java#L170]
> method passes any null {{SolrDocument}} through to the
> [JSONWriter.writeSolrDocument|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/JSONWriter.java#L87]
> method leading to a {{NullPointerException}} at line 87.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13496) NullPointerException in JSONWriter.writeSolrDocument
[
https://issues.apache.org/jira/browse/SOLR-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857506#comment-16857506
]
Christine Poerschke commented on SOLR-13496:
bq. ... I think that's unrelated ... SOLR-13518 just opened to improve the
debuggability of that test.
Actually the bot was right and the SOLR-13518 change helps to make it easier to
see why, it was basically saying that
{{ChaoticDistributedGroupingTest.TargettedChaosComponent.getDescription}}
returning {{null}} is not okay.
Will attach revised patch for a QA re-run (but as mentioned above am still not
intending to commit the {{ChaoticDistributedGroupingTest}} test itself).
> NullPointerException in JSONWriter.writeSolrDocument
>
>
> Key: SOLR-13496
> URL: https://issues.apache.org/jira/browse/SOLR-13496
> Project: Solr
> Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13496.patch, SOLR-13496.patch
>
>
> For non-grouped searches
> [QueryComponent.regularFinishStage|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L647-L655]
> already considers the possibility of null {{SolrDocument}} values due to an
> index change.
> For grouped searches
> [GroupedEndResultTransformer.transform|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/endresulttransformer/GroupedEndResultTransformer.java#L94-L114]
> potentially adds a null element to a {{SolrDocumentList}}.
> The
> [TextResponseWriter.writeSolrDocumentList|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java#L170]
> method passes any null {{SolrDocument}} through to the
> [JSONWriter.writeSolrDocument|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/response/JSONWriter.java#L87]
> method leading to a {{NullPointerException}} at line 87.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12589) metrics name should not contains "/" path seperator while using SolrGangliaReporter
[ https://issues.apache.org/jira/browse/SOLR-12589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-12589: --- Fix Version/s: (was: 8.1) > metrics name should not contains "/" path seperator while using > SolrGangliaReporter > --- > > Key: SOLR-12589 > URL: https://issues.apache.org/jira/browse/SOLR-12589 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3.1, 7.4, 8.0 >Reporter: weizhenyuan >Priority: Minor > Fix For: master (9.0) > > Attachments: SOLR-12589-1.diff, SOLR-12589-2.diff, SOLR-12589-3.diff > > > As I was using SolrGangliaReporter, default metrics names will contains > "/", which is > offen used in FileSystem as an seperator, than it encounters ERROR cause > creating > metrics data file failed, bellow is the Exception in /var/log/messages: > Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: Unable to write meta data > for metric > solr.node.QUERY.httpShardHandler.http_//hb-bp1tg6t003y04p201-003.hbase.rds.aliyuncs.com_8983/solr/admin/cores.post.requests.p999 > to RRD > Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/cores.requestTimes.p999.rrd': > No such file or directory > Jul 25 15:01:37 hb-bp1tg6t003y04p201-001 gmetad: Unable to write meta data > for metric solr.node.ADMIN./admin/cores.requestTimes.p999 to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/collections.requestTimes.min.rrd': > No such file or directory > Jul 25 15:01:37 localhost gmetad: Unable to write meta data for metric > solr.node.ADMIN./admin/collections.requestTimes.min to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/authorization.requestTimes.stddev.rrd': > No such file or directory > Jul 25 15:01:37 localhost gmetad: Unable to write meta data for metric > solr.node.ADMIN./admin/authorization.requestTimes.stddev to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.ADMIN./admin/autoscaling/history.requestTimes.p99.rrd': > No such file or directory > Jul 25 15:01:37 localhost gmetad: Unable to write meta data for metric > solr.node.ADMIN./admin/autoscaling/history.requestTimes.p99 to RRD > Jul 25 15:01:37 localhost gmetad: RRD_create: creating > '/var/lib/ganglia/rrds/__SummaryInfo__/solr.node.QUERY./admin/autoscaling.timeouts.m1_rate.rrd': > No such file or directory > I think the metrics name should be normalized for different reporter，such as > SolrGangliaReport. > Some times other normalization is used for other reason，but now，for > ganglia，It must > replace the "/" . -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12573) Config and using SolrGangliaReporter, encounters an ClassNotDefException
[ https://issues.apache.org/jira/browse/SOLR-12573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-12573: --- Fix Version/s: (was: 8.1) > Config and using SolrGangliaReporter, encounters an ClassNotDefException > > > Key: SOLR-12573 > URL: https://issues.apache.org/jira/browse/SOLR-12573 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 7.3.1, 7.4, 8.0 >Reporter: weizhenyuan >Priority: Minor > Labels: build, patch > Fix For: master (9.0) > > Attachments: ExceptionDetail.log, SOLR-12573-1.patch > > > Config and using SolrGangliaReporter, then start solr service encounters the > ClassNotDefException bellow: > java.lang.NoClassDefFoundError: org/acplt/oncrpc/XdrEncodingStream > at info.ganglia.gmetric4j.gmetric.GMetric.(GMetric.java:82) > at info.ganglia.gmetric4j.gmetric.GMetric.(GMetric.java:58) > at info.ganglia.gmetric4j.gmetric.GMetric.(GMetric.java:40) > at > org.apache.solr.metrics.reporters.SolrGangliaReporter.lambda$start$0(SolrGangliaReporter.java:106) > at > org.apache.solr.metrics.reporters.ReporterClientCache.getOrCreate(ReporterClientCache.java:59) > at > org.apache.solr.metrics.reporters.SolrGangliaReporter.start(SolrGangliaReporter.java:106) > at > .. > Caused by: java.lang.ClassNotFoundException: > org.acplt.oncrpc.XdrEncodingStream > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:448) > at java.lang.ClassLoader.loadClass(ClassLoader.java:380) > It should be configurated an dependency in solr/server/ivy.xml as default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12447) Allow SimplePostTool to POST hidden files.
[ https://issues.apache.org/jira/browse/SOLR-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-12447: --- Fix Version/s: (was: 8.1) > Allow SimplePostTool to POST hidden files. > -- > > Key: SOLR-12447 > URL: https://issues.apache.org/jira/browse/SOLR-12447 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.0 >Reporter: Ian Goldsmith-Rooney >Priority: Minor > Labels: newbie, patch > Fix For: master (9.0) > > Attachments: SOLR-12447.patch > > > Currently, the SimplePostTool ignores all hidden files without a toggle. This > feature will add a toggle to allow POSTing hidden files for indexing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11718) Deprecate CDCR Buffer APIs and set Buffer to "false"
[ https://issues.apache.org/jira/browse/SOLR-11718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856998#comment-16856998 ] Christine Poerschke commented on SOLR-11718: Hello. Could we confirm here if changes are included in the (already released) 8.1 version which is (currently) tagged as fixVersion. It appears from ticket updates and cursory CHANGES.txt scan that nothing was committed here yet – if that is correct, may I suggest to un-tag the fixVersion 8.1 portion? Thanks! > Deprecate CDCR Buffer APIs and set Buffer to "false" > > > Key: SOLR-11718 > URL: https://issues.apache.org/jira/browse/SOLR-11718 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-11718.patch, SOLR-11718.patch, SOLR-11718.patch > > > Kindly see the discussion on SOLR-11652. > Today, if we see the current CDCR documentation page, buffering is "disabled" > by default in both source and target. We don't see any purpose served by Cdcr > buffering and it is quite an overhead considering it can take a lot heap > space (tlogs ptr) and forever retention of tlogs on the disk when enabled. > Also today, even if we disable buffer from API on source , considering it was > enabled at startup, tlogs are never purged on leader node of shards of > source, refer jira: SOLR-11652 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11528) ltr unit tests failed when run as JUnit in Eclipse Oxygen
[ https://issues.apache.org/jira/browse/SOLR-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-11528: --- Fix Version/s: (was: 8.1) (was: master (9.0)) > ltr unit tests failed when run as JUnit in Eclipse Oxygen > -- > > Key: SOLR-11528 > URL: https://issues.apache.org/jira/browse/SOLR-11528 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Affects Versions: 8.0 > Environment: eclipse oxygen >Reporter: jin jing >Priority: Major > Attachments: SOLR-11528.patch > > > If we build the lucene project first and then run the ltr unit test, it will > have the following error: > ERROR: [doc=1] unknown field 'description' > i found this is beacuse of the under the floader > solr\contrib\ltr\src\test-files we shoud modify solr\collection1\conf to > ltr\solr\collection1\conf. and we shoud Specify solrhome in TestRerankBase. > If you do not modify the path schema may be overwritten -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8150) Remove references to segments.gen.
[
https://issues.apache.org/jira/browse/LUCENE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856996#comment-16856996
]
Christine Poerschke commented on LUCENE-8150:
-
Hello. Could we confirm here if changes are included in the (already released)
8.1 version which is (currently) tagged as fixVersion. It appears from ticket
updates and cursory CHANGES.txt scan that nothing was committed here yet – if
that is correct, may I suggest to un-tag the fixVersion 8.1 portion? Thanks!
> Remove references to segments.gen.
> --
>
> Key: LUCENE-8150
> URL: https://issues.apache.org/jira/browse/LUCENE-8150
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8150.patch, LUCENE-8150.patch
>
>
> This was the way we wrote pending segment files before we switch to
> {{pending_segments_N}} in LUCENE-5925.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
