[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=16827057#comment-16827057
]
matthew medway commented on SOLR-13240:
---
yea, I'm pretty frustrated about that as well. 7.5's auto scaling features
worked great since release until i randomly ran into this. Ill eventually try
8.0 since they made more changes and fixes to autoscaling but until then this
patch works great.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>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
>
[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=16827009#comment-16827009
]
matthew medway commented on SOLR-13240:
---
Thanks so much guys i think we fixed it.
I found the new jar here:
ls -al
/home/ubuntu/solrbuild/solr-7.5.0/solr/build/solr-solrj/solr-solrj-7.5.0-SNAPSHOT.jar
(renamed to to remove -SNAPSHOT)
old jar here:
ls -al /opt/solr/server/solr-webapp/webapp/WEB-INF/lib | grep solr-solrj
#old file size: 1870892
#new file size: 1871143
#backup existing
cp /opt/solr/server/solr-webapp/webapp/WEB-INF/lib/solr-solrj-7.5.0.jar
/opt/solr/server/solr-webapp/webapp/WEB-INF/lib/solr-solrj-7.5.0.jar.old
#copy over the new:
cp /home/ubuntu/solr-solrj-7.5.0.jar
/opt/solr/server/solr-webapp/webapp/WEB-INF/lib/solr-solrj-7.5.0.jar
#restarted solr:
service solr restart
repeat the above for all solr web nodes i the cluster
now my curl works!
:~# curl
'http://localhost:8983/solr/admin/collections?action=UTILIZENODE=172.27.9.167:8983_solr'
{
"responseHeader":{
"status":0,
"QTime":69948}}
For the convenience of anyone else who comes along to this issue ive attached
the updated solr-solrj-7.5.0.jar file so that they can easily copy it over top
of the old one:
/opt/solr/server/solr-webapp/webapp/WEB-INF/lib/solr-solrj-7.5.0.jar
Thanks!
-Matt
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>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
[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
]
matthew medway updated SOLR-13240:
--
Attachment: solr-solrj-7.5.0.jar
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>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] [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=16826956#comment-16826956
]
matthew medway commented on SOLR-13240:
---
I compiled the jars this time using ant jar and i found the two locations for
the jars:
current service:
ls -al /opt/solr/server/solr-webapp/webapp/WEB-INF/lib
new jars:
ls -al
/home/ubuntu/solrbuild/solr-7.5.0/solr/server/solr-webapp/webapp/WEB-INF/lib
For this specific edit to MoveReplicaSuggester.java do you know what jar files
i should be moving? They all have identical sizes in this directory so im not
sure
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch
>
>
> 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=16826943#comment-16826943
]
matthew medway commented on SOLR-13240:
---
Nice, ill give that a try
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch
>
>
> 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-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826461#comment-16826461
]
matthew medway commented on SOLR-13240:
---
I'm also having this problem in version 7.5. I'm not exactly sure how exactly
I triggered it to happen but I added two new solr web nodes to my cluster (3 to
5 nodes total), one of them auto-scaled correctly and moved replicas to it, the
other one just sat there and did nothing.
I can run the command for the new node:
*curl
'http://localhost:8983/solr/admin/collections?action=UTILIZENODE=172.27.9.167:8983_solr'*
from any of the servers and i receive the same error as you guys:
*"Operation utilizenode caused
exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
Comparison method violates its general contract!"*
I tried to use your patch but i don't think i did it correctly. Here were my
steps:
#patching solr 7.5
mkdir solrbuild
cd solrbuild
apt install ant -y
wget http://archive.apache.org/dist/lucene/solr/7.5.0/solr-7.5.0-src.tgz
tar -xvf solr-7.5.0-src.tgz
#cd
solr-7.5.0/solr-7.5.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/
#apply the patch
#wget
'https://issues.apache.org/jira/secure/attachment/12963112/SOLR-13240.patch' -O
- | patch -p1 --dry-run
nano
solr-7.5.0/solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/MoveReplicaSuggester.java
#update the code
cd solr-7.5.0/
ant ivy-bootstrap
ant compile
cd solr
ant server
tar -cvzf /home/ubuntu/solrbuild/solr-7.5.0.tgz
/home/ubuntu/solrbuild/solr-7.5.0/solr
#download the file to the servers you need to install it to. it should be about
160mb
#install the patched version over top of the existing
mkdir -p /home/ubuntu/solrbuild/
chmod 666 /home/ubuntu/solrbuild/
/home/ubuntu/solr-7.5.0/bin/install_solr_service.sh
/home/ubuntu/solrbuild/solr-7.5.0.tgz -f
What do you guys think? I'm out of ideas and dont really want to move 300+
replicas manually.
Thanks!
-Matt
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch
>
>
> 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] [Commented] (SOLR-12814) Metrics history causing "HttpParser URI is too large >8192" when many collections
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636097#comment-16636097
]
matthew medway commented on SOLR-12814:
---
yay!!
> Metrics history causing "HttpParser URI is too large >8192" when many
> collections
> -
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Assignee: Jan Høydahl
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Fix For: 7.5.1, 7.6, master (8.0)
>
> Attachments: longmetricsquery.txt, screencapture-cloud-graph.png,
> screencapture-nodes-actual-IP.png, screenshot-debug.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
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-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630804#comment-16630804
]
matthew medway commented on SOLR-12814:
---
Amazing! looking forward to your next update thanks!
> Metrics page causing "HttpParser URI is too large >8192"
>
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Attachments: longmetricsquery.txt
>
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
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-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630665#comment-16630665
]
matthew medway edited comment on SOLR-12814 at 9/27/18 4:05 PM:
Hrmm. The nodes page is still working this time, maybe its because i had the
bigger headers set earlier today. I am now getting the error about URI being
too large again:
cat /var/solr/logs/solr.log | grep -i WARN -B 10 -A 10
{code:java}
--
2018-09-27 15:58:49.887 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system params={wt=json&_=1538063896110} status=0
QTime=7
2018-09-27 15:58:49.902 INFO (qtp534906248-19) [ ] o.a.s.h.a.CollectionsHandler
Invoked Collection Action :list with params action=LIST=json&_=1538063896110
and sendToOCPQueue=true
2018-09-27 15:58:49.902 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=LIST=json&_=1538063896110} status=0 QTime=0
2018-09-27 15:58:49.927 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=CLUSTERSTATUS=json&_=1538063896110} status=0 QTime=41
2018-09-27 15:58:49.977 INFO (qtp534906248-21) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system
params={wt=javabin=2&_=1538063896110} status=0 QTime=31
2018-09-27 15:58:49.978 INFO (qtp534906248-14) [ ] o.a.s.h.a.AdminHandlersProxy
Fetched response from 3 nodes: [172.19.1.223:8983_solr, 172.19.7.118:8983_solr,
172.19.0.107:8983_solr]
2018-09-27 15:58:49.978 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system
params={nodes=172.19.0.107:8983_solr,172.19.1.223:8983_solr,172.19.7.118:8983_solr=json&_=1538063896110}
status=0 QTime=36
2018-09-27 15:58:49.996 INFO (qtp534906248-18) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={prefix=CONTAINER.fs,org.eclipse.jetty.server.handler.DefaultHandler.get-requests,INDEX.sizeInBytes,SEARCHER.searcher.numDocs,SEARCHER.searcher.deletedDocs,SEARCHER.searcher.warmupTime=javabin=2&_=1538063896206}
status=0 QTime=38
2018-09-27 15:58:49.998 INFO (qtp534906248-19) [ ] o.a.s.h.a.AdminHandlersProxy
Fetched response from 3 nodes: [172.19.1.223:8983_solr, 172.19.7.118:8983_solr,
172.19.0.107:8983_solr]
2018-09-27 15:58:49.998 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={nodes=172.19.0.107:8983_solr,172.19.1.223:8983_solr,172.19.7.118:8983_solr=CONTAINER.fs,org.eclipse.jetty.server.handler.DefaultHandler.get-requests,INDEX.sizeInBytes,SEARCHER.searcher.numDocs,SEARCHER.searcher.deletedDocs,SEARCHER.searcher.warmupTime=json&_=1538063896206}
status=0 QTime=54
2018-09-27 15:59:03.747 WARN (qtp534906248-12) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 15:59:03.753 INFO (qtp534906248-17) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=1
2018-09-27 16:00:02.130 INFO (qtp534906248-12) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics params={} status=0 QTime=311
2018-09-27 16:00:02.206 INFO (qtp534906248-21) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics params={} status=0 QTime=388
2018-09-27 16:00:02.230 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics params={} status=0 QTime=404
2018-09-27 16:00:03.856 WARN (qtp534906248-12) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 16:00:03.859 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 16:00:19.599 INFO (qtp534906248-12) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/cores params={indexInfo=false=json&_=1538063985822}
status=0 QTime=0
2018-09-27 16:00:19.601 INFO (qtp534906248-17) [ ] o.a.s.h.a.CollectionsHandler
Invoked Collection Action :clusterstatus with params
action=CLUSTERSTATUS=json&_=1538063985823 and sendToOCPQueue=true
2018-09-27 16:00:19.612 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system params={wt=json&_=1538063985823} status=0
QTime=12
2018-09-27 16:00:19.624 INFO (qtp534906248-18) [ ] o.a.s.h.a.CollectionsHandler
Invoked Collection Action :list with params action=LIST=json&_=1538063985823
and sendToOCPQueue=true
2018-09-27 16:00:19.625 INFO (qtp534906248-18) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=LIST=json&_=1538063985823} status=0 QTime=0
2018-09-27 16:00:19.659 INFO (qtp534906248-17) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null
[jira] [Commented] (SOLR-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630665#comment-16630665
]
matthew medway commented on SOLR-12814:
---
Hrmm. The nodes page is still working this time, maybe its because i had the
bigger headers set earlier today. I am now getting the error about URI being
too large again:
{code:java}
--
2018-09-27 15:58:49.887 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system params={wt=json&_=1538063896110} status=0
QTime=7
2018-09-27 15:58:49.902 INFO (qtp534906248-19) [ ] o.a.s.h.a.CollectionsHandler
Invoked Collection Action :list with params action=LIST=json&_=1538063896110
and sendToOCPQueue=true
2018-09-27 15:58:49.902 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=LIST=json&_=1538063896110} status=0 QTime=0
2018-09-27 15:58:49.927 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=CLUSTERSTATUS=json&_=1538063896110} status=0 QTime=41
2018-09-27 15:58:49.977 INFO (qtp534906248-21) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system
params={wt=javabin=2&_=1538063896110} status=0 QTime=31
2018-09-27 15:58:49.978 INFO (qtp534906248-14) [ ] o.a.s.h.a.AdminHandlersProxy
Fetched response from 3 nodes: [172.19.1.223:8983_solr, 172.19.7.118:8983_solr,
172.19.0.107:8983_solr]
2018-09-27 15:58:49.978 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system
params={nodes=172.19.0.107:8983_solr,172.19.1.223:8983_solr,172.19.7.118:8983_solr=json&_=1538063896110}
status=0 QTime=36
2018-09-27 15:58:49.996 INFO (qtp534906248-18) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={prefix=CONTAINER.fs,org.eclipse.jetty.server.handler.DefaultHandler.get-requests,INDEX.sizeInBytes,SEARCHER.searcher.numDocs,SEARCHER.searcher.deletedDocs,SEARCHER.searcher.warmupTime=javabin=2&_=1538063896206}
status=0 QTime=38
2018-09-27 15:58:49.998 INFO (qtp534906248-19) [ ] o.a.s.h.a.AdminHandlersProxy
Fetched response from 3 nodes: [172.19.1.223:8983_solr, 172.19.7.118:8983_solr,
172.19.0.107:8983_solr]
2018-09-27 15:58:49.998 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={nodes=172.19.0.107:8983_solr,172.19.1.223:8983_solr,172.19.7.118:8983_solr=CONTAINER.fs,org.eclipse.jetty.server.handler.DefaultHandler.get-requests,INDEX.sizeInBytes,SEARCHER.searcher.numDocs,SEARCHER.searcher.deletedDocs,SEARCHER.searcher.warmupTime=json&_=1538063896206}
status=0 QTime=54
2018-09-27 15:59:03.747 WARN (qtp534906248-12) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 15:59:03.753 INFO (qtp534906248-17) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=1
2018-09-27 16:00:02.130 INFO (qtp534906248-12) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics params={} status=0 QTime=311
2018-09-27 16:00:02.206 INFO (qtp534906248-21) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics params={} status=0 QTime=388
2018-09-27 16:00:02.230 INFO (qtp534906248-19) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics params={} status=0 QTime=404
2018-09-27 16:00:03.856 WARN (qtp534906248-12) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 16:00:03.859 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 16:00:19.599 INFO (qtp534906248-12) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/cores params={indexInfo=false=json&_=1538063985822}
status=0 QTime=0
2018-09-27 16:00:19.601 INFO (qtp534906248-17) [ ] o.a.s.h.a.CollectionsHandler
Invoked Collection Action :clusterstatus with params
action=CLUSTERSTATUS=json&_=1538063985823 and sendToOCPQueue=true
2018-09-27 16:00:19.612 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/info/system params={wt=json&_=1538063985823} status=0
QTime=12
2018-09-27 16:00:19.624 INFO (qtp534906248-18) [ ] o.a.s.h.a.CollectionsHandler
Invoked Collection Action :list with params action=LIST=json&_=1538063985823
and sendToOCPQueue=true
2018-09-27 16:00:19.625 INFO (qtp534906248-18) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=LIST=json&_=1538063985823} status=0 QTime=0
2018-09-27 16:00:19.659 INFO (qtp534906248-17) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/collections
params={action=CLUSTERSTATUS=json&_=1538063985823} status=0 QTime=58
2018-09-27 16:00:19.702 INFO
[jira] [Comment Edited] (SOLR-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630626#comment-16630626
]
matthew medway edited comment on SOLR-12814 at 9/27/18 3:42 PM:
yea, without doing anything i can run "tail -f /var/solr/logs/solr.log" and
just watch for the error to happen.
I should clarify that the metrics api works fine but the nodes page is not
showing stats correctly just like [~elyograg] said
was (Author: mmedway):
yea, without doing anything i can run "tail -f /var/solr/logs/solr.log" and
just watch for the error to happen.
> Metrics page causing "HttpParser URI is too large >8192"
>
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Attachments: longmetricsquery.txt
>
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
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-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630626#comment-16630626
]
matthew medway commented on SOLR-12814:
---
yea, without doing anything i can run "tail -f /var/solr/logs/solr.log" and
just watch for the error to happen.
> Metrics page causing "HttpParser URI is too large >8192"
>
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Attachments: longmetricsquery.txt
>
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
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-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
matthew medway updated SOLR-12814:
--
Description:
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
was:
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
> Metrics page causing "HttpParser URI is too large >8192"
>
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Priority: Major
> Labels: URI, header, http,
[jira] [Updated] (SOLR-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
matthew medway updated SOLR-12814:
--
Description:
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
was:
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
2018-09-27 13:06:45.430 WARN (qtp534906248-16) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
> Metrics page causing "HttpParser URI is too large >8192"
>
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>
[jira] [Updated] (SOLR-12814) Metrics page causing "HttpParser URI is too large >8192"
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
matthew medway updated SOLR-12814:
--
Description:
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
2018-09-27 13:06:45.430 WARN (qtp534906248-16) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
was:
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
2018-09-27 13:06:45.430 WARN (qtp534906248-16) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
> Metrics page causing "HttpParser URI is too large >8192"
>
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper
[jira] [Created] (SOLR-12814) Metrics page causing "HttpParser URI is too large >8192"
matthew medway created SOLR-12814:
-
Summary: Metrics page causing "HttpParser URI is too large >8192"
Key: SOLR-12814
URL: https://issues.apache.org/jira/browse/SOLR-12814
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: metrics, SolrCloud
Affects Versions: 7.5
Environment: 3x zookeeper and 3x solr cloud servers,
50 test collections with 0 data in them
Reporter: matthew medway
Attachments: longmetricsquery.txt
If you have a lot of collections, like 50 or more, the new metrics page in
version 7.5 can't run its queries because the default
solr.jetty.request.header.size and solr.jetty.response.header.size values are
too small.
If I up the header values from 8192 to 65536 the commands will work.
command to change the defaults:
{code:java}
sed -i 's/\"solr.jetty.request.header.size\"
default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml sed -i 's/\"solr.jetty.response.header.size\"
default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
/opt/solr/server/etc/jetty.xml
{code}
before changing the header size log:
2018-09-27 13:06:45.430 WARN (qtp534906248-16) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code:java}
2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall [admin]
webapp=null path=/admin/metrics
params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
status=0 QTime=0
2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
too large >8192
{code}
After changing the header size log:
{code:java}
attached as a file because its very long and ugly{code}
Is it possible to break up this command into batches so that it can run without
modifying the header sizes?
Thanks!
-Matt
--
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
