Updated to include Redis/Resque versions and stack trace (below):
redis (3.0.4)
redis-namespace (1.3.0)
redis (~> 3.0.0)
redis-store (1.1.2)
redis (>= 2.2.0)
resque (1.24.1)
mono_logger (~> 1.0)
multi_json (~> 1.0)
redis-namespace (~> 1.2)
sinatra (>= 0.9.2)
vegas (~> 0.1.2)
resque-scheduler (2.0.1)
redis (>= 2.0.1)
resque (>= 1.20.0)
rufus-scheduler
I'm seeing intermittent Redis::TimeoutError: Connection timed out on heroku while writing a moderately sized array (~200 Fixnums) to the Redis store using the Rails.cache.fetch command.
I'm also using Resque.
I see here that the Redis::Client can receive a timeout option, but I don't see where to pass initialization options to Redis.
I'm using the standard heroku resque.rb:
rails_root = ENV['RAILS_ROOT'] || File.dirname(__FILE__) + '/../..'
rails_env = ENV['RAILS_ENV'] || 'development'
resque_config = YAML.load_file(rails_root + '/config/resque.yml')
ENV['REDIS_URI'] = resque_config[rails_env]
Resque.redis = resque_config[rails_env]
Resque.inline = rails_env == 'test'
require 'resque_scheduler'
require 'resque/scheduler'
require 'resque_scheduler/server'
Resque.schedule = YAML.load_file(rails_root + '/config/resque-schedule.yml')
Resque.before_fork do
defined?(ActiveRecord::Base) and
ActiveRecord::Base.connection.disconnect!
end
Resque.after_fork do
defined?(ActiveRecord::Base) and
ActiveRecord::Base.establish_connection
end
I assume that a Redis client is instantiated here. Is this a different client from the one instantiated in production.rb:
rails_root = ENV['RAILS_ROOT'] || File.dirname(__FILE__) + '/../..'
rails_env = ENV['RAILS_ENV'] || 'development'
resque_config = YAML.load_file(rails_root + '/config/resque.yml')
config.cache_store = :redis_store, resque_config[rails_env], { expires_in: 14.days }
The options hash there is for Rails.cache options as far as I know. Is a new client instantiated here? How can I pass options to this one?
Updated to include this experiment in the heroku console implying that they are different client instances:
irb(main):002:0> Rails.cache
=> #<ActiveSupport::Cache::RedisStore:0x00000003860e18 #data=#<Redis client v3.0.4 for redis://spinyfin.redistogo.com:9485/0>, #options={:expires_in=>14 days}>
irb(main):003:0> Resque.redis.redis
=> #<Redis client v3.0.4 for redis://spinyfin.redistogo.com:9485/0>
irb(main):004:0> Rails.cache.instance_variable_get(:#data).object_id == Resque.redis.redis.object_id
=> false
Stack trace:
Redis::TimeoutError: Connection timed out
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:208:in `rescue in io'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:206:in `io'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:214:in `read'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:84:in `block in call'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:187:in `block (2 levels) in process'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:295:in `ensure_connected'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:177:in `block in process'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:256:in `logging'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:176:in `process'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:84:in `call'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:644:in `block in setex'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:36:in `block in synchronize'
from /app/vendor/ruby-1.9.3/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:36:in `synchronize'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:643:in `setex'
from /app/vendor/bundle/ruby/1.9.1/gems/redis-store-1.1.2/lib/redis/store/interface.rb:17:in `setex'
... 11 levels...
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/cache.rb:299:in `fetch'
...SNIP...
...my code...
...SNIP...
from /app/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.13/lib/active_record/relation/delegation.rb:6:in `each'
from /app/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.13/lib/active_record/relation/delegation.rb:6:in `each'
...SNIP...
...my code...
...SNIP...
from (irb):5
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/commands/console.rb:47:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/commands/console.rb:8:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/commands.rb:41:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'irb(main):006:0> ! Heroku client internal error.
! Search for help at: https://help.heroku.com
! Or report a bug at: https://github.com/heroku/heroku/issues/new
Error: Operation timed out (Errno::ETIMEDOUT)
Backtrace: /usr/local/heroku/ruby/lib/ruby/1.9.1/openssl/buffering.rb:121:in `sysread'
/usr/local/heroku/ruby/lib/ruby/1.9.1/openssl/buffering.rb:121:in `readpartial'
/Users/me/.heroku/client/lib/heroku/client/rendezvous.rb:69:in `block in start'
/Users/me/.heroku/client/lib/heroku/client/rendezvous.rb:53:in `loop'
/Users/me/.heroku/client/lib/heroku/client/rendezvous.rb:53:in `start'
/Users/me/.heroku/client/lib/heroku/command/run.rb:132:in `rendezvous_session'
/Users/me/.heroku/client/lib/heroku/command/run.rb:119:in `run_attached'
/Users/me/.heroku/client/lib/heroku/command/run.rb:24:in `index'
/Users/me/.heroku/client/lib/heroku/command.rb:206:in `run'
/Users/me/.heroku/client/lib/heroku/cli.rb:28:in `start'
/usr/local/heroku/bin/heroku:24:in `<main>'
Command: heroku run rails c
Plugins: heroku-redis-cli
Version: heroku-toolbelt/2.39.4 (x86_64-darwin10.8.0) ruby/1.9.3
The "Connection timed out" message means that redis-rb is having trouble initiating a connection to your Redis server. Normally, you'd want to just initialize your Redis connection once on app boot. However, because Resque forks (rather than using threads like Sidekiq), it has to initialize a fresh Redis connection for every individual job.
Normally, that's not a problem, but Heroku has intermittent issues with creating new Redis connections. I've seen this issue across languages / client libraries / Redis hosts, and beyond reducing the number of Redis connections you create, the only way to mitigate the issue is to automatically retry connecting to Redis a few times in your Resque.after_fork block. (Eg. catch the timeout error and either retry or re-raise the exception if you've tried 3 times)
This isn't much of an answer, but at the recommendation of a colleague, I switched from RedisToGo to openredis and these problems went away immediately.
You can't pass both a URL and an options hash to config.cache_store, because of this bug:
config.cache_store = :redis_store, resque_config[rails_env], { expires_in: 14.days }
If you pass a URL and an options hash, it ignores the URL and defaults to localhost, which is probably why you're seeing a timeout (I just had the same issue).
Instead, do something like this:
redis_uri = URI.parse(ENV["REDISTOGO_URL"])
config.cache_store = :redis_store, {
host: redis_uri.host,
port: redis_uri.port,
password: redis_uri.password,
namespace: "cache",
expires_in: 7.days
}
Related
I have a rails app on heroku that uses Resque.enqueu to schedule background jobs using Redis and redistogo.
Jobs used to work normally but I notice now that they have all been failing for some time (a few weeks, 100% of jobs).
The error I get:
Exception Errno::ETIMEDOUT Error Connection timed out - connect(2)
And the stack trace:
> /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:878:in `initialize'
> /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:878:in `open'
> /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:878:in `block in
> connect' /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/timeout.rb:52:in
> `timeout' /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:877:in
> `connect' /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:862:in
> `do_start' /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:851:in
> `start' /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1373:in
> `request' /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1131:in
> `get'
> /app/vendor/bundle/ruby/2.0.0/gems/activeresource-4.0.0/lib/active_resource/connection.rb:121:in `block in request'
> /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.1/lib/active_support/notifications.rb:164:in
> `block in instrument'
> /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.1/lib/active_support/notifications/instrumenter.rb:20:in
> `instrument'
> /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.1/lib/active_support/notifications.rb:164:in
> `instrument'
> /app/vendor/bundle/ruby/2.0.0/gems/activeresource-4.0.0/lib/active_resource/connection.rb:118:in `request'
> /app/vendor/bundle/ruby/2.0.0/gems/shopify_api-4.0.6/lib/active_resource/connection_ext.rb:13:in `request_with_detailed_log_subscriber'
> /app/vendor/bundle/ruby/2.0.0/gems/activeresource-4.0.0/lib/active_resource/connection.rb:82:in
> `block in get'
> /app/vendor/bundle/ruby/2.0.0/gems/activeresource-4.0.0/lib/active_resource/connection.rb:216:in `with_auth'
> /app/vendor/bundle/ruby/2.0.0/gems/activeresource-4.0.0/lib/active_resource/connection.rb:82:in
> `get'
> /app/vendor/bundle/ruby/2.0.0/gems/activeresource-4.0.0/lib/active_resource/custom_methods.rb:57:in
> `get'
> /app/vendor/bundle/ruby/2.0.0/gems/shopify_api-4.0.6/lib/shopify_api/countable.rb:4:in
> `count' /app/app/models/shop.rb:263:in `unscanned_customers'
> /app/app/models/shop.rb:230:in `shopify_customers'
> /app/app/models/shop.rb:144:in `bulk_scan'
> /app/app/workers/bulk_scanner.rb:16:in `perform'
I was thinking maybe it is something to do with not connecting to Redis or redistogo properly. Here are the relevant initializer code that I have:
resque.rb:
Resque.redis = RedisConnection.connection
redis_connection.rb:
class RedisConnection
def self.close
connection.quit
end
def self.connection
#connection ||= new_connection
end
def self.new_connection
uri = URI.parse(ENV['REDISTOGO_URL'] || 'redis://localhost:6379/')
Redis.new(host: uri.host,
port: uri.port,
password: uri.password,
thread_safe: true,
:timeout => 1)
end
end
If I call Resque.redis or #connection in my app, it returns a Redis instance. What else would be causing this connection error? Where can I troubleshoot?
Looking at the Backtrace, could it be a Shopify API connection timeout?
It looks like unscanned_customers is a supposed to be a countable Shopify collection and the problem occurs when an attempt to retrieve the customer is made.
I would start my debugging here:
> 'count' /app/app/models/shop.rb:263:in
'unscanned_customers'
Additionally, I would attempt to connect to Shopify from the server with a private app API key and password:
shop_url = "https://#{API_KEY}:#{PASSWORD}#SHOP_NAME.myshopify.com/admin"
ShopifyAPI::Base.site = shop_url
Refer to the Shopify API for more details if needed Shopify API Readme
It will help isolate the connection issue.
Cheers.
I got a simple and free heroku app running where I added redis/sidekiq in order to send out mails in the background. I set everything up and once I start the worker, I get following error message in a loop:
Error fetching job: ERR max number of clients reached
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:114:in `call'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:95:in `block in connect'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:280:in `with_reconnect'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:93:in `connect'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:351:in `ensure_connected'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:208:in `block in process'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:293:in `logging'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:207:in `process'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:113:in `call'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:196:in `block in call_with_timeout'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:267:in `with_socket_timeout'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:195:in `call_with_timeout'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:1097:in `block in _bpop'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:57:in `block in synchronize'
/app/vendor/ruby-2.2.2/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:57:in `synchronize'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:1094:in `_bpop'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:1139:in `brpop'
/app/vendor/bundle/ruby/2.2.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:393:in `call_with_namespace'
/app/vendor/bundle/ruby/2.2.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:290:in `method_missing'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/fetch.rb:35:in `block in retrieve_work'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq.rb:84:in `block in redis'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:64:in `block (2 levels) in with'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:63:in `handle_interrupt'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:63:in `block in with'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:60:in `handle_interrupt'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:60:in `with'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq.rb:81:in `redis'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/fetch.rb:35:in `retrieve_work'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:85:in `get_one'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:95:in `fetch'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:78:in `process_one'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:67:in `run'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/util.rb:16:in `watchdog'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/util.rb:24:in `block in safe_thread'
sidekiq.yml:
---
:queues:
- default
- mailers
sidekiq.rb:
Sidekiq.configure_server do |config|
config.redis = { :namespace => "mynamespace" }
end
Sidekiq.configure_client do |config|
config.redis = { :namespace => "mynamespace" }
end
require "sidekiq/web"
Sidekiq::Web.app_url = "/"
Sidekiq::Web.use(Rack::Auth::Basic, "Application") do |username, password|
username == ENV.fetch("SIDEKIQ_WEB_USERNAME") &&
password == ENV.fetch("SIDEKIQ_WEB_PASSWORD")
end
Anyone an idea what's wrong here? If you need any further info on the config files or something, let me know.
Changing sidekiq.yml to
---
:queues:
- default
- mailers
:concurrency: 5
did the trick. Setting concurrency to 9 did not for some reason even though heroku allows 10 for the redis nano addon.
This was the best solution that I found. If you are using the free heroku plan and the free redis nano plan. All the connections have to add up to 10 or less. To make sure that the connections add up check out this blog post. http://manuelvanrijn.nl/blog/2012/11/13/sidekiq-on-heroku-with-redistogo-nano/
He explains how everything adds up.
The writer also has a calculator that will help to calculate what the configuration should be for your particular server, sidekiq etc. It also tells you where the information needs to be added.
I was stuck on this too hope it saves somebody some time :)
For some reason, on heroku it will not allow me to import models (this is for the Bonsai ElasticSearch add-on). It's just showing connection refused. I'm not sure how to resolve this. I've searched the internet and I can't find anything that will even hint me in the right direction to solve this. I checked to make sure the server was up and manually created the index with curl. Do the initializers get launched when running a rake task?
I set the elasticsearch url in the config/initializers/bonsai.rb file:
config/initializers/bonsai.rb
if Rails.env == 'production'
ENV['ELASTICSEARCH_URL'] = ENV['BONSAI_URL']
end
Gemfile snippet
# Used for elastic search
gem 'elasticsearch-model', github: 'elasticsearch/elasticsearch-rails'
gem 'elasticsearch-rails', github: 'elasticsearch/elasticsearch-rails'
gem 'multi_json'
gem 'json'
Error
heroku run rake environment elasticsearch:import:all DIR=app/models
Running `rake environment elasticsearch:import:all DIR=app/models` attached to terminal... up, run.5751
[IMPORT] Loading models from: app/models
[IMPORT] Processing model: Firm...
rake aborted!
Connection refused - connect(2)
/app/vendor/bundle/ruby/2.0.0/gems/faraday-0.9.0/lib/faraday/adapter/net_http.rb:80:in `perform_request'
/app/vendor/bundle/ruby/2.0.0/gems/faraday-0.9.0/lib/faraday/adapter/net_http.rb:39:in `call'
/app/vendor/bundle/ruby/2.0.0/gems/faraday-0.9.0/lib/faraday/rack_builder.rb:139:in `build_response'
/app/vendor/bundle/ruby/2.0.0/gems/faraday-0.9.0/lib/faraday/connection.rb:377:in `run_request'
/app/vendor/bundle/ruby/2.0.0/gems/elasticsearch-transport-1.0.1/lib/elasticsearch/transport/transport/http/faraday.rb:21:in `block in perform_request'
/app/vendor/bundle/ruby/2.0.0/gems/elasticsearch-transport-1.0.1/lib/elasticsearch/transport/transport/base.rb:187:in `call'
/app/vendor/bundle/ruby/2.0.0/gems/elasticsearch-transport-1.0.1/lib/elasticsearch/transport/transport/base.rb:187:in `perform_request'
/app/vendor/bundle/ruby/2.0.0/gems/elasticsearch-transport-1.0.1/lib/elasticsearch/transport/transport/http/faraday.rb:20:in `perform_request'
/app/vendor/bundle/ruby/2.0.0/gems/elasticsearch-transport-1.0.1/lib/elasticsearch/transport/client.rb:102:in `perform_request'
/app/vendor/bundle/ruby/2.0.0/gems/elasticsearch-api-1.0.1/lib/elasticsearch/api/actions/bulk.rb:81:in `bulk'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-model/lib/elasticsearch/model/importing.rb:78:in `block in import'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-model/lib/elasticsearch/model/adapters/active_record.rb:88:in `block in __find_in_batches'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.0/lib/active_record/relation/batches.rb:125:in `find_in_batches'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.0/lib/active_record/querying.rb:9:in `find_in_batches'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-model/lib/elasticsearch/model/proxy.rb:80:in `method_missing'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-model/lib/elasticsearch/model/adapters/active_record.rb:86:in `__find_in_batches'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-model/lib/elasticsearch/model/importing.rb:77:in `import'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-model/lib/elasticsearch/model.rb:113:in `import'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-rails/lib/elasticsearch/rails/tasks/import.rb:59:in `block (3 levels) in <top (required)>'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-rails/lib/elasticsearch/rails/tasks/import.rb:99:in `block (4 levels) in <top (required)>'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-rails/lib/elasticsearch/rails/tasks/import.rb:82:in `each'
/app/vendor/bundle/ruby/2.0.0/bundler/gems/elasticsearch-rails-26a3ba246968/elasticsearch-rails/lib/elasticsearch/rails/tasks/import.rb:82:in `block (3 levels) in <top (required)>'
Tasks: TOP => elasticsearch:import:model
(See full trace by running task with --trace)
by the way can someone create an 'elasticsearch-rails' tag since its the upcoming replacement for Tire
Elasticsearch Rails does not use the same mechanism as Tire to set its URL in production on Heroku. To have this work correctly with Bonsai search, you have to have a different url specification. Fortunately a guy has made a gem (https://rubygems.org/gems/bonsai-elasticsearch-rails) to eliminate the needless, mandatory creation of a initializer by everyone.
Simply add this gem to your gem file under your production group. The version may be subject to change since it's so new:
gem 'bonsai-elasticsearch-rails', '~> 0.0.4'
If you're more curious about what this gem actually does, the entire source is below:
require "bonsai/elasticsearch/rails/version"
puts "Starting up a new ElasticSearch client with #{ENV['BONSAI_URL']}"
Elasticsearch::Model.client = Elasticsearch::Client.new url: ENV['BONSAI_URL']
I know, simple right...
In my rails 2.3.8 app running in windows 7, getting the following error when attempting to start the server:
D:\app1>ruby script/server
C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- active_support/core_ext (LoadError)
from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from D:/app1/vendor/rails/activesupport/lib/active_support.rb:56
from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from D:/app1/vendor/rails/railties/lib/commands/server.rb:1
from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from script/server:3
In the custom require file block below... line 36 is "gem_original_require path"
def require(path) # :doc:
gem_original_require path
rescue LoadError => load_error
if load_error.message =~ /#{Regexp.escape path}\z/ and
spec = Gem.searcher.find(path) then
Gem.activate(spec.name, "= #{spec.version}")
gem_original_require path
else
raise load_error
end
end
gem list as follows:
actionmailer (2.3.8)
actionpack (2.3.8)
activerecord (2.3.8)
activeresource (2.3.8)
activesupport (2.3.8)
builder (3.0.0)
calendar_date_select (1.16.1)
cgi_multipart_eof_fix (2.5.0)
gem_plugin (0.2.3)
google4r-checkout (1.0.6.1)
i18n (0.5.0)
liquid (2.2.2)
money (3.5.5)
mongrel (1.1.5 x86-mingw32)
mysql (2.8.1 x86-mingw32)
rack (1.1.0)
rails (2.3.8)
rake (0.8.7)
rmagick (2.12.0 mswin32)
Looked around with portions of the error, but I'm not quite sure where to start.
Just looking at the stack trace ... it looks like your application is on drive "D" and the ruby files are on drive "C".
Maybe when its performing the require
filenames = Dir["#{File.dirname(__FILE__)}/core_ext/*.rb"].sort.map do |path|
File.basename(path, '.rb')
end
its requiring that path on "D" when it should be on "C". That's my best guess. Good luck.
create a file name
core_ext.rb
in the
C:\Ruby\lib\ruby\gems\1.8\gems\activesupport-2.3.8\lib\active_support
and edit add the content to the following lines
filenames = Dir["#{File.dirname(__FILE__)}/core_ext/*.rb"].sort.map do |path|
File.basename(path, '.rb')
end
# deprecated
filenames -= %w(blank)
filenames.each { |filename| require "active_support/core_ext/#{filename}" }
I include this simple Rack Middleware in a Rails application:
class Hello
def initialize(app)
#app = app
end
def call(env)
[200, {"Content-Type" => "text/html"}, "Hello"]
end
end
Plug it in inside environment.rb:
...
Dir.glob("#{RAILS_ROOT}/lib/rack_middleware/*.rb").each do |file|
require file
end
Rails::Initializer.run do |config|
config.middleware.use Hello
...
I'm using Rails 2.3.5, Webrick 1.3.1, ruby 1.8.7
When the application is started in production mode, everything works as expected - every request is intercepted by the Hello middleware, and "Hello" is returned. However, when run in development mode, the very first request works returning "Hello", but the next request hangs.
Interrupting webrick while it is in the hung state yields this:
^C[2010-03-24 14:31:39] INFO going to shutdown ...
deadlock 0xb6efbbc0: sleep:- - /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:31
deadlock 0xb7d1b1b0: sleep:J(0xb6efbbc0) (main) - /usr/lib/ruby/1.8/webrick/server.rb:113
Exiting
/usr/lib/ruby/1.8/webrick/server.rb:113:in `join': Thread(0xb7d1b1b0): deadlock (fatal)
from /usr/lib/ruby/1.8/webrick/server.rb:113:in `start'
from /usr/lib/ruby/1.8/webrick/server.rb:113:in `each'
from /usr/lib/ruby/1.8/webrick/server.rb:113:in `start'
from /usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
from /usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
from /usr/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/handler/webrick.rb:14:in `run'
from /usr/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/commands/server.rb:111
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from script/server:3
Something to do with the class reloader in development mode. There is also mention of deadlock in the exception.
Any ideas what might be causing this? Any recommendations as to the best approach to debug this?
UPDATE
$ script/console
Loading development environment (Rails 2.3.5)
>> app.get '/'
=> 200
>> app.get '/'
ThreadError: stopping only thread
note: use sleep to stop forever
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:31:in `lock'
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:31:in `run'
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:108:in `call'
from /usr/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/lint.rb:47:in `_call'
from /usr/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/lint.rb:35:in `call'
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/integration.rb:316:in `process'
from /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/integration.rb:197:in `get'
from (irb):2
Looks like it might be related to this issue:
https://rails.lighthouseapp.com/projects/8994/tickets/3153-actioncontrollerintegrationsession-broken-in-234
I've come up with a hack that will get me by the time being. It's on the ticket mentioned above.
https://rails.lighthouseapp.com/projects/8994/tickets/3153-actioncontrollerintegrationsession-broken-in-234