lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rallavagu <>
Subject Re: Solr 4.6.1 Cloud Stops Replication
Date Tue, 18 Aug 2015 16:03:44 GMT
Thanks Shawn.

All participating cloud nodes are running Tomcat and as you suggested 
will review the number of threads and increase them as needed.

Essentially, what I have noticed was that two of four nodes caught up 
with "bulk" updates instantly while other two nodes took almost 3 hours 
to completely in sync with "leader". I have "tickled" other nodes by 
sending an update thinking that it would initiate the replication but 
not sure if that caused other two nodes to eventually catch up.

On similar note, I was using "CouncurrentUpdateSolrServer" directly 
pointing to leader to bulk load Solr cloud. I have configured the chunk 
size and thread count for the same. Is this the right practice to bulk 
load SolrCloud?

Also, the maximum number of connections per host parameter for 
"HttpShardHandler" is in solrconfig.xml I suppose?


On 8/18/15 8:28 AM, Shawn Heisey wrote:
> On 8/18/2015 8:18 AM, Rallavagu wrote:
>> Thanks for the response. Does this cache behavior influence the delay
>> in catching up with cloud? How can we explain solr cloud replication
>> and what are the option to monitor and take proactive action (such as
>> initializing, pausing etc) if needed?
> I don't know enough about your setup to speculate.
> I did notice this exception in a previous reply:
> org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for
> connection from pool
> I can think of two things that would cause this.
> One cause is that your servlet container is limiting the number of
> available threads.  A typical jetty or tomcat default for maxThreads is
> 200, which can easily be exceeded by a small Solr install, especially if
> it's SolrCloud.  The jetty included with Solr sets maxThreads to 10000,
> which is effectively unlimited except for extremely large installs.  If
> you are providing your own container, this will almost certainly need to
> be raised.
> The other cause is that your install is extremely busy and you have run
> out of available HttpClient connections.  The solution in this case is
> to increase the maximum number of connections per host in the
> HttpShardHandler config, which defaults to 20.
> There might be other causes for that exception, but I think those are
> the most common causes.  Depending on how things are set up, you have
> problems with both.
> Thanks,
> Shawn

View raw message