6

I'm trying to setup SOLR Cloud to work with my Sitecore 8.2 (original release) instance. I'm doing this because our analytics index has gotten to the point where our massive SOLR box (90 Gb RAM, 16 Processors) can't handle the load. The SOLR Documentation recommends using the SOLR Cloud configuration so that we can split the index up among different boxes. Here's the error that we are getting from the Sitecore log:

8416 08:54:21 ERROR <?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><bool name="zkConnected">true</bool><int name="status">500</int><int name="QTime">2</int><lst name="params"><str name="q">(_template:(e07c277f59684cc097bc8b3195159f56) AND associated_articles_sm:(90e745382dcd439bb507f7af92a2ce56))</str><str name="fq">_indexname:(sitecore_web_index)</str><str name="rows">2147483647</str><str name="version">2.2</str></lst></lst><lst name="error"><str name="trace">java.lang.NegativeArraySizeException
    at org.apache.lucene.util.PriorityQueue.&lt;init&gt;(PriorityQueue.java:63)

And here's another part of the error:

Source: SolrNet
   at SolrNet.Impl.SolrConnection.Get(String relativeUrl, IEnumerable`1 parameters)
   at SolrNet.Impl.SolrQueryExecuter`1.Execute(ISolrQuery q, QueryOptions options)
   at Sitecore.ContentSearch.SolrProvider.LinqToSolrIndex`1.Execute(SolrCompositeQuery compositeQuery, Type resultType)
Nested Exception
Exception: System.Net.WebException
Message: The remote server returned an error: (500) Internal Server Error.
Source: System
   at System.Net.HttpWebRequest.GetResponse()

The odd thing is that when we try to access the SOLR server from that same machine, we don't have any issue doing that at all. We have the ZooKeeper configured properly, behind an IIS Site that acts as a load balancer for the ZooKeeper/SOLRCloud instances. Most of the site seems to work properly, but there are a couple of indexes that don't appear to be working correctly, and this error seems to be why. I've also looked at this link but it's not helped to solve my problem.

We are running the latest version of 6.x for SOLR. I don't know if that contributes to anything else or not. I'm not sure what my next steps need to be to help figure out what is wrong with my SOLR configuration. This does seem to be a SOLR Cloud configuration issue, as I'm running everything fine in my test environment which is running just a standard version of SOLR.

How do I begin figuring out what is going on with this? Thanks!

Update

To answer the questions asked, I was able to send this query with no problems: http://MySolrIP:8983/solr/sitecore_web_index/select?indent=on&wt=json

I was also able to make this query without any errors as well:

http://MySOlrIP:8983/solr/sitecore_web_index/select?indent=on&q=_template:(e07c277f59684cc097bc8b3195159f56)&associated_articles_sm:(90e745382dcd439bb507f7af92a2ce56)&rows=50&wt=json

I'm thinking that it might be related to this error that we're seeing in the Sitecore logs:

2017-03-08 03:06:15.487 ERROR (qtp1983747920-9187) [c:mediaframework_ooyala_index s:shard2 r:core_node1 x:mediaframework_ooyala_index_shard2_replica1] o.a.s.h.RequestHandlerBase java.lang.NegativeArraySizeException
        at org.apache.lucene.util.PriorityQueue.<init>(PriorityQueue.java:63)
        at org.apache.lucene.util.PriorityQueue.<init>(PriorityQueue.java:44)
        at org.apache.solr.handler.component.ShardFieldSortedHitQueue.<init>(ShardFieldSortedHitQueue.java:45)
        at org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:979)
        at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:763)
        at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:742)
        at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:428)
        at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
        at org.apache.solr.core.SolrCore.execute(SolrCore.java:2306)
        at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
        at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
        at org.eclipse.jetty.server.Server.handle(Server.java:534)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
        at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
        at java.lang.Thread.run(Thread.java:745)

Possibly unrelated, but maybe not, when we started running the query in the GUI we are now seeing this warning in the logs:

2017-03-08 17:05:42.511 WARN  (qtp1983747920-15) [c:sitecore_web_index s:shard1 r:core_node3 x:sitecore_web_index_shard1_replica1] o.e.j.h.HttpParser bad HTTP parsed: 400 HTTP/0.9 not supported for HttpChannelOverHttp@77faac88{r=0,c=false,a=IDLE,uri=null}

Thank you for your help!

Improve this question
4
  • I noticed that this was your query: (_template:(e07c277f59684cc097bc8b3195159f56) AND associated_articles_sm:(90e745382dcd439bb507f7af92a2ce56)). Have you tried searching without a query? If doing so still returns the error in the log can you show us what is logged? If doing so doesn't return the error, let us know as that may help to inform our solutions. :)
    – Zachary Kniebel
    Commented Mar 7, 2017 at 19:26
  • Additionally, can you open up your Solr Admin, go to the logs, run your search and then copy the error(s) that you get there into here?
    – Zachary Kniebel
    Commented Mar 7, 2017 at 19:34
  • I work with Keith and am helping troubleshoot this problem. The xml response error doesn't happen when we manually adjust the query rows= from the 2.1 billion rows down to 1 billion rows. Is there a way to tell sitecore 8.2 to use a smaller number in its requesthandler or solr.contentsearch maybe? I don't know how sitecore communicates that value but I check the solrconfig.xml and it is defaulting returned rows to 10 in its requesthandler and says a request will override these parameters.
    – Darren Walker
    Commented Mar 9, 2017 at 15:46
  • We've addressed an issue somewhat similar by adjusting ContentSearch.SearchMaxResults (defined in Sitecore.ContentSearch.config). You can set an explicit limit there, and the Sitecore ContentSearch API will pass that to the requestHandler. Default is int.MaxValue which is pretty big :) Ultimately, our root cause was some custom ContentSearch code not properly paging, but enforcing a limit was a temp work-around.
    – G Killian
    Commented Mar 9, 2017 at 18:45

1 Answer 1

Reset to default
3

I ended up attacking this from the solr side. In the solrconfig.xml I added an invariant to rows and after a rebuild the site is working as expected. It looks like this:

<requestHandler name="/select" class="solr.SearchHandler">
<!-- default values for query parameters can be specified, these
     will be overridden by parameters in the request
  -->
 <lst name="defaults">
   <str name="echoParams">explicit</str>
 </lst>
 <lst name="invariants">
   <int name="rows">500000</int>
 </lst>

</requestHandler>

Thanks for sharing what config on the sitecore side sets the max int value-I was curious on how to do this on the client side of the request so I wouldn't have to hard code an invariant in solr.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.