RE: Flying Sphinx and Sidekiq

Question

I'm afraid I've reached a point of total helplessness re: Flying Sphinx and Sidekiq. It appears that Sidekiq and FS are not able to communicate in production.

I am in TS3 and using Sidekiq to run delta indexing - it works great in development and actually worked for some time in production yesterday. But today when I run:

heroku run bundle exec sidekiq -q ts_delta

I get the following error:

undefined local variable or method `decode_frame' for

WebSocket::Frame::Incoming::Server:0x000000048cac40

and at the end a long series of:

Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected Disconnect attempted... not connected

I can provide more info on this so we can solve it together - am at my computer until about 2 AM today (it's already been a long day) and can rpovide any info necessary!

I just don't want to overload with info right away.

Fingers crosses,

Laurent.

PS: including the error report from new relick:

action.rb: 22:in sleep' …flying-sphinx-e1395e724afb/lib/flying_sphinx/action.rb: 22:inblock in perform'
/usr/local/lib/ruby/1.9.1/timeout.rb: 58:in timeout' …flying-sphinx-e1395e724afb/lib/flying_sphinx/action.rb: 15:inperform'
…flying-sphinx-e1395e724afb/lib/flying_sphinx/action.rb: 5:in perform' …ng-sphinx-e1395e724afb/lib/flying_sphinx/controller.rb: 37:inindex'
…/lib/thinking_sphinx/deltas/sidekiq_delta/delta_job.rb: 14:in perform' …uby/1.9.1/gems/sidekiq-2.10.1/lib/sidekiq/processor.rb: 49:inblock (3 levels) in process'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 109:in call' ….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 109:inblock in invoke'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 111:in block in invoke' …idekiq-2.10.1/lib/sidekiq/middleware/server/timeout.rb: 14:incall'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 111:in block in invoke' …-2.10.1/lib/sidekiq/middleware/server/active_record.rb: 6:incall'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware//app/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rbchain.rb: 111:in block in invoke' …kiq-2.10.1/lib/sidekiq/middleware/server/retry_jobs.rb: 50:incall'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 111:in block in invoke' …idekiq-2.10.1/lib/sidekiq/middleware/server/logging.rb: 11:inblock in call'
…/ruby/1.9.1/gems/sidekiq-2.10.1/lib/sidekiq/logging.rb: 22:in with_context' …idekiq-2.10.1/lib/sidekiq/middleware/server/logging.rb: 7:incall'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 111:in block in invoke' ….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 114:incall'
….1/gems/sidekiq-2.10.1/lib/sidekiq/middleware/chain.rb: 114:in invoke' …uby/1.9.1/gems/sidekiq-2.10.1/lib/sidekiq/processor.rb: 48:inblock (2 levels) in process'
…uby/1.9.1/gems/sidekiq-2.10.1/lib/sidekiq/processor.rb: 87:in stats' …uby/1.9.1/gems/sidekiq-2.10.1/lib/sidekiq/processor.rb: 47:inblock in process'
…uby/1.9.1/gems/celluloid-0.12.4/lib/celluloid/calls.rb: 23:in call' …uby/1.9.1/gems/celluloid-0.12.4/lib/celluloid/calls.rb: 23:inpublic_send'
…uby/1.9.1/gems/celluloid-0.12.4/lib/celluloid/calls.rb: 23:in dispatch' …by/1.9.1/gems/celluloid-0.12.4/lib/celluloid/future.rb: 18:inblock in initialize'
…1/gems/celluloid-0.12.4/lib/celluloid/internal_pool.rb: 48:in call' …1/gems/celluloid-0.12.4/lib/celluloid/internal_pool.rb: 48:inblock in create

Answer 1

Discussed this issue with Laurent directly through support channels. The main problem here was that websocket (used by the flying-sphinx gem) uses autoload, which doesn't play nicely with Sidekiq. Switching the production Rails environment to be threadsafe must tweak something in autoload, because it fixed this problem.

So: if you're using Sidekiq, make sure your environment has threadsafe enabled, and even better, don't use autoload (Matz is planning to remove it after Ruby 2.0).