Couldn't cleanly terminate all actors in 10 seconds!

[szyablitsky]

Upgraded to the last version of a gem (1.6.0). Now I get this error every time I exit rails console. Rails version is 4.2.4.

[merqlove]

Same here, but in tests.

[pabse]

Same problem here. If I remove this gem from Gemfile the console exits normally again.

[aried3r]

Same here. This is especially frustrating since starting and terminating tests, rubocop etc take an extra ten seconds.

@brandonhilkert, I guess this would be solved by the rewrite in 2.0 using concurrent_ruby, but any chance of a fix for the 1.x series?

[brandonhilkert]

@aried3r Haven't had time to dig in to it. Presumably there's a Celluloid setting where you could shut this off, but not sure off hand. Might be worth pinging their google group if you have a chance.

[flaviomori]

+1

[drueck]

I experienced the same issue with my app running on Heroku with sucker_punch 1.6.0. In addition, the non-clean exit appeared to be leaking database connections. Each time I restarted my app's dynos it would increment the number of current database connections by 1, eventually causing it to max out the connections and crash. I reverted to 1.5.1 and things seem to be working fine. (Just thought I'd add my experience for others troubleshooting the issue).

[nynhex]

@drueck @brandonhilkert I have the same problem with 1.6.0 in addition to the ops issue. Rails 4.2.4 Ruby 2.2.2 Sucker Punch 1.6.0. I'm going to try 1.5.1.

[nynhex]

@drueck @brandonhilkert FYI I reverted to 1.5.1 and am not experiencing any problems whatsoever. No problems with actors, connection pool leakage, or memory leakage.

[brandonhilkert]

Must be the Celluloid bump then. Stick with that if it works better until I release the next version that removes Celluloid altogether.

---

_Build a Ruby Gem is available! http://brandonhilkert.com/books/build-a-ruby-gem/?utm_source=gmail-sig&utm_medium=email&utm_campaign=gmail_

http://brandonhilkert.com

On Sun, Dec 27, 2015 at 4:16 PM, James notifications@github.com wrote:

@drueck https://github.com/drueck @brandonhilkert https://github.com/brandonhilkert FYI I reverted to 1.5.1 and am not experiencing any problems whatsoever. No problems with actors, connection pool leakage, or memory leakage.

— Reply to this email directly or view it on GitHub https://github.com/brandonhilkert/sucker_punch/issues/135#issuecomment-167441968 .

[nynhex]

Thanks for the quick reply. Will keep an eye out for the next release :+1:

[brandonhilkert]

2.0.0.beta1 was released this morning. Please give it a shot and let me know how it goes :)

[nynhex]

@brandonhilkert Thanks, I'll give it a try in a test branch and post up results! :+1:

[nynhex]

@brandonhilkert was going to ask if the 2.0.0beta1 will work with ruby 1.9.3. I'm dealing with a legacy app which is why I ask.

[merqlove]

Seems that 2.0 will be on top of concurrent-ruby, which required_ruby_version '>= 1.9.3'. Same here, also have one pretty old spree app on 1.9.3 with sucker_punch inside.

[merqlove]

Thanks!

[brandonhilkert]

The docs say 2.0 and above, but I've really just removed those versions from CI. There's nothing that's 2.0+ specific, assuming concurrent-ruby is compatible.

[drueck]

I can't fully test this yet because I'm using SuckerPunch via ActiveJob, but it appears upgrading to 2.0.0.beta1 solved this issue as expected. No more waiting for 10 seconds when you shut down your app server. :) Thanks!

[nynhex]

This is great news! I'm going to see if I can run this on 1.9.3.

[nickgnd]

The issue is closed, but maybe it could help. I encountered the same error message with sucker_punch v.1.5.1, celluloid v.0.16.0 and Ruby v.2.2.0

E, [2016-06-16T11:41:18.601619 #1235] ERROR -- : Couldn't cleanly terminate all actors in 10 seconds!

A little of context of my script:

• In the class which include SuckerPunch::Job I limit the workers number to 2
• In the main script I start 3 different sucker_punch workers consecutively, something like this:

worker1 = WriterWorker.new.async.perform(data1)
worker2 = WriterWorker.new.async.perform(data2)
worker3 = WriterWorker.new.async.perform(data3)

In my case I was able to solve in this two simple ways:

• Insert a sleep at the end of the script

or

• Increase the workers number to 3 (without put additional sleep)