# Rails client getting socket connect timeouts regularly **URL:** \ **Category:** Elasticsearch\ **Created:** [August 6, 2012, 3:56pm UTC](https://discuss.elastic.co/t/rails-client-getting-socket-connect-timeouts-regularly/8651 "2012-08-06T15:56:30Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![T\_Vinod\_Gupta](https://avatars.discourse-cdn.com/v4/letter/t/fbc32d/32.png) [@T\_Vinod\_Gupta](https://discuss.elastic.co/u/T_Vinod_Gupta)\ **Post date:** [August 6, 2012, 3:56pm UTC](https://discuss.elastic.co/t/rails-client-getting-socket-connect-timeouts-regularly/8651/1 "2012-08-06T15:56:30Z")
hi, we have an ES index that is accessed by a rails server.. things work well in general. but every few minutes (once/twice an hour), the client gets a socket connect failure from the ES server. has anyone seen this and if yes, what is the solution? our ES host is running healthy with heavy write/read operations going in parallel from java clients. the only difference i see is that in the java clients, we have a pool of Client objects that we reuse and dont create a new client for each operation. are there any best practices here? should there be a http connection pooling between rails client and ES server? it is not trivial to do in rails as each web request goes to a separate process. here is the stack trace every time it happens - /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `initialize' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in`open' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `open_socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:227:in`connect' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:294:in `socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:159:in`request' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/adapter/excon.rb:15:in `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/response.rb:8:in`call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/request/json.rb:32:in `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:210:in`run\_request' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:93:in `get' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:54:in`get' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:79:in `mget' thanks ---
**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:** [August 7, 2012, 9:36pm UTC](https://discuss.elastic.co/t/rails-client-getting-socket-connect-timeouts-regularly/8651/2 "2012-08-07T21:36:38Z")
First, from Java there isn't a need to pool Client objects, you can just use a single Client in your application (its perfectly thread safe). Regarding the rails client, can you possibly monitor the number of open sockets you have on the machine, maybe you are opening and closing sockets from rails where the OS is starting to throttle it? Any chance of trying and use persistent connections from rails? On Aug 6, 2012, at 5:56 PM, T Vinod Gupta [tvinod@readypulse.com](mailto:tvinod@readypulse.com) wrote: > hi, > we have an ES index that is accessed by a rails server.. things work well in general. but every few minutes (once/twice an hour), the client gets a socket connect failure from the ES server. has anyone seen this and if yes, what is the solution? our ES host is running healthy with heavy write/read operations going in parallel from java clients. the only difference i see is that in the java clients, we have a pool of Client objects that we reuse and dont create a new client for each operation. > > are there any best practices here? should there be a http connection pooling between rails client and ES server? it is not trivial to do in rails as each web request goes to a separate process. > > here is the stack trace every time it happens - > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `initialize' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `open' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `open_socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:227:in `connect' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:294:in `socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:159:in `request' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/adapter/excon.rb:15:in `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/response.rb:8:in `call' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/request/json.rb:32:in `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:210:in `run\_request' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:93:in `get' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:54:in `get' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:79:in `mget' > > thanks ---
**Author:** ![T\_Vinod\_Gupta](https://avatars.discourse-cdn.com/v4/letter/t/fbc32d/32.png) [@T\_Vinod\_Gupta](https://discuss.elastic.co/u/T_Vinod_Gupta)\ **Post date:** [August 7, 2012, 9:42pm UTC](https://discuss.elastic.co/t/rails-client-getting-socket-connect-timeouts-regularly/8651/3 "2012-08-07T21:42:17Z")
thanks for the tip on java client object. i didnt know it was thread safe. ill take a look at open sockets as you suggested. do you know of any rails library/gem that lets you do persistent connections to ES? do people implement their own wrapper/abstraction here? thanks On Tue, Aug 7, 2012 at 2:36 PM, Shay Banon [kimchy@gmail.com](mailto:kimchy@gmail.com) wrote: > First, from Java there isn't a need to pool Client objects, you can just > use a single Client in your application (its perfectly thread safe). > > Regarding the rails client, can you possibly monitor the number of open > sockets you have on the machine, maybe you are opening and closing sockets > from rails where the OS is starting to throttle it? Any chance of trying > and use persistent connections from rails? > > On Aug 6, 2012, at 5:56 PM, T Vinod Gupta [tvinod@readypulse.com](mailto:tvinod@readypulse.com) wrote: > > hi, > we have an ES index that is accessed by a rails server.. things work well > in general. but every few minutes (once/twice an hour), the client gets a > socket connect failure from the ES server. has anyone seen this and if yes, > what is the solution? our ES host is running healthy with heavy write/read > operations going in parallel from java clients. the only difference i see > is that in the java clients, we have a pool of Client objects that we reuse > and dont create a new client for each operation. > > are there any best practices here? should there be a http connection > pooling between rails client and ES server? it is not trivial to do in > rails as each web request goes to a separate process. > > here is the stack trace every time it happens - > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in > `initialize' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `open' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in > `open_socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:227:in `connect' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:294:in > `socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:159:in `request' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/adapter/excon.rb:15:in > `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/response.rb:8:in `call' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/request/json.rb:32:in > `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:210:in `run\_request' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:93:in > `get' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:54:in `get' > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:79:in > `mget' > > thanks ---
**Author:** ![Shairon\_Toledo](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shairon_toledo/32/2490_2.png) [@Shairon\_Toledo](https://discuss.elastic.co/u/Shairon_Toledo)\ **Post date:** [August 8, 2012, 11:51am UTC](https://discuss.elastic.co/t/rails-client-getting-socket-connect-timeouts-regularly/8651/4 "2012-08-08T11:51:57Z")
We've been used rubberband ruby gem for more than 4 months we didn't get any issue with timeout. Rubberband gets nodes list from [http://node:9200/\_nodes](http://node:9200/_nodes) before each search or index in the same request, it also has built-in retry, failover and others features, maybe this implementation fits better in your Rails env. > **[GitHub - grantr/rubberband: ElasticSearch Ruby client (deprecated)](https://github.com/grantr/rubberband)** > > ElasticSearch Ruby client (deprecated). Contribute to grantr/rubberband development by creating an account on GitHub. On Tue, Aug 7, 2012 at 6:42 PM, T Vinod Gupta [tvinod@readypulse.com](mailto:tvinod@readypulse.com) wrote: > thanks for the tip on java client object. i didnt know it was thread safe. > > ill take a look at open sockets as you suggested. do you know of any rails > library/gem that lets you do persistent connections to ES? do people > implement their own wrapper/abstraction here? > > thanks > > On Tue, Aug 7, 2012 at 2:36 PM, Shay Banon [kimchy@gmail.com](mailto:kimchy@gmail.com) wrote: > > > First, from Java there isn't a need to pool Client objects, you can just > > use a single Client in your application (its perfectly thread safe). > > > > Regarding the rails client, can you possibly monitor the number of open > > sockets you have on the machine, maybe you are opening and closing sockets > > from rails where the OS is starting to throttle it? Any chance of trying > > and use persistent connections from rails? > > > > On Aug 6, 2012, at 5:56 PM, T Vinod Gupta [tvinod@readypulse.com](mailto:tvinod@readypulse.com) wrote: > > > > hi, > > we have an ES index that is accessed by a rails server.. things work well > > in general. but every few minutes (once/twice an hour), the client gets a > > socket connect failure from the ES server. has anyone seen this and if yes, > > what is the solution? our ES host is running healthy with heavy write/read > > operations going in parallel from java clients. the only difference i see > > is that in the java clients, we have a pool of Client objects that we reuse > > and dont create a new client for each operation. > > > > are there any best practices here? should there be a http connection > > pooling between rails client and ES server? it is not trivial to do in > > rails as each web request goes to a separate process. > > > > here is the stack trace every time it happens - > > > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in > > `initialize' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in `open' > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:288:in > > `open_socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:227:in `connect' > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:294:in > > `socket' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/excon-0.6.6/lib/excon/connection.rb:159:in `request' > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/adapter/excon.rb:15:in > > `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/response.rb:8:in `call' > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/request/json.rb:32:in > > `call' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:210:in `run\_request' > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/faraday-0.7.6/lib/faraday/connection.rb:93:in > > `get' /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:54:in `get' > > /usr/local/rvm/gems/ruby-1.9.3-p0/gems/elasticsearch-client-0.0.6/lib/elasticsearch.rb:79:in > > `mget' > > > > thanks -- Shairon Toledo > **[Microsoft Developer News | C++,C# & .NET Framework & More | CodeGuru](http://hashcode.me)** > > 您是否想要找关于幸运飞行艇 官方开奖历史记录 168飞艇全国统一开奖数据 还有幸运飞行艇官方开奖现场直播 幸运168飞艇全天精准稳定计划 这里都能一一提供。CodeGuru is where developers come to share ideas, articles, questions, answers, tips, tricks, comments, downloads, and more related to programming in areas including C++,... ---
**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:17am UTC](https://discuss.elastic.co/t/rails-client-getting-socket-connect-timeouts-regularly/8651/5 "2017-07-06T03:17:14Z")