Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Event Machine next_tick causing EM reactor lock and thread lock #244

Open
inventionlabsSydney opened this issue Aug 12, 2014 · 5 comments · May be fixed by #267
Open

Event Machine next_tick causing EM reactor lock and thread lock #244

inventionlabsSydney opened this issue Aug 12, 2014 · 5 comments · May be fixed by #267

Comments

@inventionlabsSydney
Copy link

Hi guys,

Current situation

Today I recently updated everything on my machine and all of a sudden things locked.
I originally thought this was a bug in thin but I've tracked it back to specifying :hiredis as the driver of websocket server and the eventual solution add an if reactor_running? and if the reactor is running use next_tick else defer with EM in connection manager.rb and removing synchro.resume out of next_tick in synchronization.rb

I will submit my patch in so you guys can see what I mean.

original problem:

When I start it using either (rails server, bundle exec rails server) I get the following:

=> Booting Thin
=> Rails 4.0.4 application starting in karlLocal on http://0.0.0.0:3000
=> Run rails server -h for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.2 codename Doc Brown)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop

Now when I go to the browser, I go to the web address (in my case http://localhost:3000) and nothing appears, no requests acknowledged not a single packet seems to be processed.

I attempt to control C to stop thin (which worked fine normally) and nothing, I don't even get the usual event machine capture "Stopping..."

=> Booting Thin
=> Rails 4.0.4 application starting in karlLocal on http://0.0.0.0:3000
=> Run rails server -h for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.2 codename Doc Brown)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop
^C^C^C^C^C^C^C^C^C^C^C^C^C

My only option is to Kill -9 the process and remove the pid file afterwards.

I've done a complete upgrade of ruby, removed any obsolete gems, ensured I'm latest stable with all of them even to the lengths of updating RVM and still. Nothing.

My configuration is as follows:
Ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-darwin13.0.0]
Rails 4.0.4
Thin 1.6.2 codename Doc Brown
Gem 2.2.0
RVM 1.25.28 (stable)
@guoyk93
Copy link

guoyk93 commented Aug 17, 2014

Same problem.

@inventionlabsSydney
Copy link
Author

@yanke-guo - you're also getting this problem?

Can I get some more information about your discoveries on this?

@guoyk93
Copy link

guoyk93 commented Sep 4, 2014

Versions:

rails (4.1.1)
      actionmailer (= 4.1.1)
      actionpack (= 4.1.1)
      actionview (= 4.1.1)
      activemodel (= 4.1.1)
      activerecord (= 4.1.1)
      activesupport (= 4.1.1)
      bundler (>= 1.3.0, < 2.0)
      railties (= 4.1.1)
      sprockets-rails (~> 2.0)
websocket-rails (0.7.0)
 thin (1.6.2)
      daemons (>= 1.0.9)
      eventmachine (>= 1.0.0)
      rack (>= 1.0.0)
redis (3.0.7)
    redis-objects (1.0.0)
      redis (>= 3.0.2)

Problem

The problem is quite wired.

When I specify a redis driver other than synchrony ( which is default ), the whole Rails application will stuck while booting.

No response to any request, cannot be stopped by Ctrl+C, only can be killed by SIGKILL.

The other problem is while using synchrony, sometimes a Fiber Error will be raised, which _DIRECTLY SHUT THE SERVER_.

So I've installed websocket_rails, but not using.

PS: I'm dumping log and analyzing, will update later.

@inventionlabsSydney inventionlabsSydney mentioned this issue Sep 23, 2014
Open
@inventionlabsSydney
Copy link
Author

Hi @yanke-guo

I've done a quick fix that seems to get past this for me, I'm finding this to be a race condition of some type.

Check out this fork and see if it runs okay for you?
https://github.com/inventionlabsSydney/websocket-rails

@inventionlabsSydney
Copy link
Author

inventionlabsSydney@d72f430 as reference.

@inventionlabsSydney inventionlabsSydney linked a pull request Sep 30, 2014 that will close this issue
Open
hkroger added a commit to hkroger/websocket-rails that referenced this issue Nov 20, 2019
@hkroger
Merge pull request #1 from inventionlabsSydney/eventmachine-redis-lock
f494783 
Attempting fix for issue websocket-rails#244
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Attempting fix for issue 244 inventionlabsSydney/websocket-rails
2 participants
@inventionlabsSydney @guoyk93