# Loop on startup doing initial recovery **URL:** \ **Category:** Elasticsearch\ **Created:** [October 2, 2011, 1:07pm UTC](https://discuss.elastic.co/t/loop-on-startup-doing-initial-recovery/5497 "2011-10-02T13:07:35Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![rrva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rrva/32/43888_2.png) [@rrva](https://discuss.elastic.co/u/rrva)\ **Post date:** [October 2, 2011, 1:07pm UTC](https://discuss.elastic.co/t/loop-on-startup-doing-initial-recovery/5497/1 "2011-10-02T13:07:35Z")
Hello list, I am using ElasticSearch embedded in a spring webapp with couchdb- river. Recently, ElasticSearch has started looping on startup when doing recovery and finally getting out of memory. Only occurs in a dev. environment (haven't been able to isolate why, the only obvious difference is Linux vs. Mac OSX and the couchdb contents.) Elasticsearch works in the same app with identical config on another machine and does not loop. I tried to point elasticsearch to a clean path.home directory but it did not change the behavior. Here is a log excerpt. What could cause this looping? Haven't been debugging ElasticSearch itself yet. 14:28:05.988 INFO s.f.search.ElasticSearchServer - Starting the Elastic Search server node 14:28:06.087 INFO org.elasticsearch.node - [Astrid Bloom] {elasticsearch/0.17.7}[473]: initializing ... 14:28:06.116 INFO org.elasticsearch.plugins - [Astrid Bloom] loaded [river-couchdb], sites [] 14:28:07.761 DEBUG org.elasticsearch.cache.memory - [Astrid Bloom] using bytebuffer cache with small\_buffer\_size [1kb], large\_buffer\_size [1mb], small\_cache\_size [10mb], large\_cache\_size [500mb], direct [true] 14:28:07.782 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [cached], type [cached], keep\_alive [30s] 14:28:07.782 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [index], type [cached], keep\_alive [5m] 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [search], type [cached], keep\_alive [5m] 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [percolate], type [cached], keep\_alive [5m] 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [management], type [scaling], min [1], size [20], keep\_alive [5m] 14:28:07.787 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [merge], type [scaling], min [1], size [20], keep\_alive [5m] 14:28:07.787 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] creating thread\_pool [snapshot], type [scaling], min [1], size [10], keep\_alive [5m] 14:28:07.801 DEBUG org.elasticsearch.transport.netty - [Astrid Bloom] using worker\_count[4], port[9300-9400], bind\_host[null], publish\_host[null], compress[false], connect\_timeout[30s], connections\_per\_node[2/4/1] 14:28:07.853 DEBUG o.e.discovery.zen.ping.multicast - [Astrid Bloom] using group [224.2.2.4], with port [54328], ttl [3], and address [null] 14:28:07.865 DEBUG o.e.discovery.zen.ping.unicast - [Astrid Bloom] using initial hosts [], with concurrent\_connects [10] 14:28:07.866 DEBUG org.elasticsearch.discovery.zen - [Astrid Bloom] using ping.timeout [3s] 14:28:07.868 DEBUG org.elasticsearch.discovery.zen.fd - [Astrid Bloom] [master] uses ping\_interval [1s], ping\_timeout [30s], ping\_retries [3] 14:28:07.888 DEBUG org.elasticsearch.discovery.zen.fd - [Astrid Bloom] [node] uses ping\_interval [1s], ping\_timeout [30s], ping\_retries [3] 14:28:08.315 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using node\_concurrent\_recoveries [2], node\_initial\_primaries\_recoveries [4] 14:28:08.315 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using [allow\_rebalance] with [indices\_all\_active] 14:28:08.316 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using [cluster\_concurrent\_rebalance] with [2] 14:28:08.346 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using node\_concurrent\_recoveries [2], node\_initial\_primaries\_recoveries [4] 14:28:08.347 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using [allow\_rebalance] with [indices\_all\_active] 14:28:08.347 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using [cluster\_concurrent\_rebalance] with [2] 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using node\_concurrent\_recoveries [2], node\_initial\_primaries\_recoveries [4] 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using [allow\_rebalance] with [indices\_all\_active] 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using [cluster\_concurrent\_rebalance] with [2] 14:28:08.395 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] using node\_concurrent\_recoveries [2], node\_initial\_primaries\_recoveries [4] .... Repeats until OOM. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 3, 2011, 9:39am UTC](https://discuss.elastic.co/t/loop-on-startup-doing-initial-recovery/5497/2 "2011-10-03T09:39:36Z")
Do you have a special type of config set? Maybe there is a wrong configuration somewhere? The library used for dependency injection (guice) gets quirky when it comes to failed to configuration and tries to create objects several times..., been meaning to fix that... . Can you try with no special config? On Sun, Oct 2, 2011 at 3:07 PM, Ragnar Rova [ragnar.rova@gmail.com](mailto:ragnar.rova@gmail.com) wrote: > Hello list, > > I am using Elasticsearch embedded in a spring webapp with couchdb- > river. Recently, Elasticsearch has started looping on startup when > doing recovery and finally getting out of memory. Only occurs in a > dev. environment (haven't been able to isolate why, the only obvious > difference is Linux vs. Mac OSX and the couchdb contents.) > Elasticsearch works in the same app with identical config on another > machine and does not loop. I tried to point elasticsearch to a clean > path.home directory but it did not change the behavior. > > Here is a log excerpt. What could cause this looping? Haven't been > debugging Elasticsearch itself yet. > > 14:28:05.988 INFO s.f.search.ElasticSearchServer - Starting the > Elastic Search server node > 14:28:06.087 INFO org.elasticsearch.node - [Astrid Bloom] > {elasticsearch/0.17.7}[473]: initializing ... > 14:28:06.116 INFO org.elasticsearch.plugins - [Astrid Bloom] loaded > [river-couchdb], sites > 14:28:07.761 DEBUG org.elasticsearch.cache.memory - [Astrid Bloom] > using bytebuffer cache with small\_buffer\_size [1kb], large\_buffer\_size > [1mb], small\_cache\_size [10mb], large\_cache\_size [500mb], direct > [true] > 14:28:07.782 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [cached], type [cached], keep\_alive [30s] > 14:28:07.782 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [index], type [cached], keep\_alive [5m] > 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [search], type [cached], keep\_alive [5m] > 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [percolate], type [cached], keep\_alive [5m] > 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [management], type [scaling], min [1], size [20], > keep\_alive [5m] > 14:28:07.787 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [merge], type [scaling], min [1], size [20], > keep\_alive [5m] > 14:28:07.787 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > creating thread\_pool [snapshot], type [scaling], min [1], size [10], > keep\_alive [5m] > 14:28:07.801 DEBUG org.elasticsearch.transport.netty - [Astrid Bloom] > using worker\_count[4], port[9300-9400], bind\_host[null], > publish\_host[null], compress[false], connect\_timeout[30s], > connections\_per\_node[2/4/1] > 14:28:07.853 DEBUG o.e.discovery.zen.ping.multicast - [Astrid Bloom] > using group [224.2.2.4], with port [54328], ttl [3], and address > [null] > 14:28:07.865 DEBUG o.e.discovery.zen.ping.unicast - [Astrid Bloom] > using initial hosts , with concurrent\_connects [10] > 14:28:07.866 DEBUG org.elasticsearch.discovery.zen - [Astrid Bloom] > using ping.timeout [3s] > 14:28:07.868 DEBUG org.elasticsearch.discovery.zen.fd - [Astrid Bloom] > [master] uses ping\_interval [1s], ping\_timeout [30s], ping\_retries [3] > 14:28:07.888 DEBUG org.elasticsearch.discovery.zen.fd - [Astrid Bloom] > [node] uses ping\_interval [1s], ping\_timeout [30s], ping\_retries [3] > 14:28:08.315 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using node\_concurrent\_recoveries [2], > node\_initial\_primaries\_recoveries [4] > 14:28:08.315 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using [allow\_rebalance] with [indices\_all\_active] > 14:28:08.316 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using [cluster\_concurrent\_rebalance] with [2] > 14:28:08.346 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using node\_concurrent\_recoveries [2], > node\_initial\_primaries\_recoveries [4] > 14:28:08.347 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using [allow\_rebalance] with [indices\_all\_active] > 14:28:08.347 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using [cluster\_concurrent\_rebalance] with [2] > 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using node\_concurrent\_recoveries [2], > node\_initial\_primaries\_recoveries [4] > 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using [allow\_rebalance] with [indices\_all\_active] > 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using [cluster\_concurrent\_rebalance] with [2] > 14:28:08.395 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > using node\_concurrent\_recoveries [2], > node\_initial\_primaries\_recoveries [4] > > .... > > Repeats until OOM. ---
**Author:** ![rrva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rrva/32/43888_2.png) [@rrva](https://discuss.elastic.co/u/rrva)\ **Post date:** [October 6, 2011, 8:48pm UTC](https://discuss.elastic.co/t/loop-on-startup-doing-initial-recovery/5497/3 "2011-10-06T20:48:02Z")
I had identical config set in both working and non-working envs. cluster.name=myname path.home=../../elasticsearch The search server was embedded using this: > On Oct 3, 11:39 am, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote: > Do you have a special type of config set? Maybe there is a wrong > configuration somewhere? The library used for dependency injection (guice) > gets quirky when it comes to failed to configuration and tries to create > objects several times..., been meaning to fix that... . Can you try with no > special config? > > On Sun, Oct 2, 2011 at 3:07 PM, Ragnar Rova [ragnar.r...@gmail.com](mailto:ragnar.r...@gmail.com) wrote: > > > Hello list, > > > I am using Elasticsearch embedded in a spring webapp with couchdb- > > river. Recently, Elasticsearch has started looping on startup when > > doing recovery and finally getting out of memory. Only occurs in a > > dev. environment (haven't been able to isolate why, the only obvious > > difference is Linux vs. Mac OSX and the couchdb contents.) > > Elasticsearch works in the same app with identical config on another > > machine and does not loop. I tried to point elasticsearch to a clean > > path.home directory but it did not change the behavior. > > > Here is a log excerpt. What could cause this looping? Haven't been > > debugging Elasticsearch itself yet. > > > 14:28:05.988 INFO s.f.search.ElasticSearchServer - Starting the > > Elastic Search server node > > 14:28:06.087 INFO org.elasticsearch.node - [Astrid Bloom] > > {elasticsearch/0.17.7}[473]: initializing ... > > 14:28:06.116 INFO org.elasticsearch.plugins - [Astrid Bloom] loaded > > [river-couchdb], sites > > 14:28:07.761 DEBUG org.elasticsearch.cache.memory - [Astrid Bloom] > > using bytebuffer cache with small\_buffer\_size [1kb], large\_buffer\_size > > [1mb], small\_cache\_size [10mb], large\_cache\_size [500mb], direct > > [true] > > 14:28:07.782 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [cached], type [cached], keep\_alive [30s] > > 14:28:07.782 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [index], type [cached], keep\_alive [5m] > > 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [search], type [cached], keep\_alive [5m] > > 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [percolate], type [cached], keep\_alive [5m] > > 14:28:07.783 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [management], type [scaling], min [1], size [20], > > keep\_alive [5m] > > 14:28:07.787 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [merge], type [scaling], min [1], size [20], > > keep\_alive [5m] > > 14:28:07.787 DEBUG org.elasticsearch.threadpool - [Astrid Bloom] > > creating thread\_pool [snapshot], type [scaling], min [1], size [10], > > keep\_alive [5m] > > 14:28:07.801 DEBUG org.elasticsearch.transport.netty - [Astrid Bloom] > > using worker\_count[4], port[9300-9400], bind\_host[null], > > publish\_host[null], compress[false], connect\_timeout[30s], > > connections\_per\_node[2/4/1] > > 14:28:07.853 DEBUG o.e.discovery.zen.ping.multicast - [Astrid Bloom] > > using group [224.2.2.4], with port [54328], ttl [3], and address > > [null] > > 14:28:07.865 DEBUG o.e.discovery.zen.ping.unicast - [Astrid Bloom] > > using initial hosts , with concurrent\_connects [10] > > 14:28:07.866 DEBUG org.elasticsearch.discovery.zen - [Astrid Bloom] > > using ping.timeout [3s] > > 14:28:07.868 DEBUG org.elasticsearch.discovery.zen.fd - [Astrid Bloom] > > [master] uses ping\_interval [1s], ping\_timeout [30s], ping\_retries [3] > > 14:28:07.888 DEBUG org.elasticsearch.discovery.zen.fd - [Astrid Bloom] > > [node] uses ping\_interval [1s], ping\_timeout [30s], ping\_retries [3] > > 14:28:08.315 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using node\_concurrent\_recoveries [2], > > node\_initial\_primaries\_recoveries [4] > > 14:28:08.315 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using [allow\_rebalance] with [indices\_all\_active] > > 14:28:08.316 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using [cluster\_concurrent\_rebalance] with [2] > > 14:28:08.346 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using node\_concurrent\_recoveries [2], > > node\_initial\_primaries\_recoveries [4] > > 14:28:08.347 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using [allow\_rebalance] with [indices\_all\_active] > > 14:28:08.347 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using [cluster\_concurrent\_rebalance] with [2] > > 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using node\_concurrent\_recoveries [2], > > node\_initial\_primaries\_recoveries [4] > > 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using [allow\_rebalance] with [indices\_all\_active] > > 14:28:08.372 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using [cluster\_concurrent\_rebalance] with [2] > > 14:28:08.395 DEBUG o.e.cluster.routing.allocation - [Astrid Bloom] > > using node\_concurrent\_recoveries [2], > > node\_initial\_primaries\_recoveries [4] > > > .... > > > Repeats until OOM. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:52am UTC](https://discuss.elastic.co/t/loop-on-startup-doing-initial-recovery/5497/4 "2017-07-06T03:52:39Z")