Celluloid actors locking up #1524

Open
griffindy opened this Issue Feb 22, 2014 · 14 comments

Comments

Projects
None yet
4 participants

I'm running Sidekiq 2.17.3 on JRuby 1.7.10. For a little while now I've been having a problem where the number of workers will go down, implying that the workers are crashing and then not being resurrected because they get stuck somewhere instantiating a new actor. I have a lot of thread dumps like the following when using jstack:

"RubyThread-190: <app home>/shared/bundle/jruby/1.9/gems/sidekiq-2.17.3/lib/sidekiq/manager.rb:35" daemon prio=10 tid=0x00007f4224050000 nid=0x310d in Object.wait() [0x00007f419fbfa000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x0000000682fa9060> (a org.jruby.ext.thread.SizedQueue)
    at java.lang.Object.wait(Object.java:461)
    at org.jruby.RubyThread$SleepTask.run(RubyThread.java:1048)
    - locked <0x0000000682fa9060> (a org.jruby.ext.thread.SizedQueue)
    at org.jruby.RubyThread.executeBlockingTask(RubyThread.java:1064)
    at org.jruby.RubyThread.wait_timeout(RubyThread.java:1412)
    at org.jruby.ext.thread.Queue.pop(Queue.java:148)
    - locked <0x0000000682fa9060> (a org.jruby.ext.thread.SizedQueue)
    at org.jruby.ext.thread.Queue.pop(Queue.java:123)
    - locked <0x0000000682fa9060> (a org.jruby.ext.thread.SizedQueue)
    at org.jruby.ext.thread.SizedQueue.pop(SizedQueue.java:105)
    - locked <0x0000000682fa9060> (a org.jruby.ext.thread.SizedQueue)
    at org.jruby.ext.fiber.ThreadFiber.resume(ThreadFiber.java:83)
    at org.jruby.ext.fiber.ThreadFiber$INVOKER$i$0$0$resume.call(ThreadFiber$INVOKER$i$0$0$resume.gen)
    at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:665)
    at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:206)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at rubyjit.Celluloid::TaskFiber$$deliver_D5F8350BA9138719B34B7CC1C13C400D330A3AA61216907342.chained_0_rescue_1$RUBY$SYNTHETIC__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks/task_fiber.rb:23)
    at rubyjit.Celluloid::TaskFiber$$deliver_D5F8350BA9138719B34B7CC1C13C400D330A3AA61216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks/task_fiber.rb)
    at rubyjit.Celluloid::TaskFiber$$deliver_D5F8350BA9138719B34B7CC1C13C400D330A3AA61216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks/task_fiber.rb)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:181)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at rubyjit.Celluloid::Task$$resume_B8B6E3AFB0A309B0B18244174C7AD920C735CA581216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks.rb:98)
    at rubyjit.Celluloid::Task$$resume_B8B6E3AFB0A309B0B18244174C7AD920C735CA581216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks.rb)
    at org.jruby.ast.executable.AbstractScript.__file__(AbstractScript.java:38)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:141)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:134)
    at rubyjit.Celluloid::Actor$$task_11EA42CB0C58CD6FBDA83E4AC512231604F4CC911216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:412)
    at rubyjit.Celluloid::Actor$$task_11EA42CB0C58CD6FBDA83E4AC512231604F4CC911216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb)
    at org.jruby.ast.executable.AbstractScript.__file__(AbstractScript.java:46)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:241)
    at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:211)
    at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:222)
    at rubyjit.Celluloid::Actor$$handle_message_3496ED653C555096413B521CD42AE830701B8E971216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:321)
    at rubyjit.Celluloid::Actor$$handle_message_3496ED653C555096413B521CD42AE830701B8E971216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:181)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at rubyjit.Celluloid::Actor$$run_500D40E0B0F9CD15C132EC746A7A0756AFC39EEC1216907342.chained_1_rescue_2$RUBY$SYNTHETIC__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:174)
    at rubyjit.Celluloid::Actor$$run_500D40E0B0F9CD15C132EC746A7A0756AFC39EEC1216907342.chained_0_rescue_1$RUBY$SYNTHETIC__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:171)
    at rubyjit.Celluloid::Actor$$run_500D40E0B0F9CD15C132EC746A7A0756AFC39EEC1216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb)
    at rubyjit.Celluloid::Actor$$run_500D40E0B0F9CD15C132EC746A7A0756AFC39EEC1216907342.__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:141)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:134)
    at rubyjit.Celluloid::Actor$$initialize_09B3FB5F9E0AE5DA1A48EC12F3F89745D65BC5901216907342.block_0$RUBY$__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:157)
    at rubyjit$Celluloid::Actor$$initialize_09B3FB5F9E0AE5DA1A48EC12F3F89745D65BC5901216907342$block_0$RUBY$__file__.call(rubyjit$Celluloid::Actor$$initialize_09B3FB5F9E0AE5DA1A48EC12F3F89745D65BC5901216907342$block_0$RUBY$__file__)
    at org.jruby.runtime.CompiledBlock19.yieldSpecificInternal(CompiledBlock19.java:117)
    at org.jruby.runtime.CompiledBlock19.yieldSpecific(CompiledBlock19.java:92)
    at org.jruby.runtime.Block.yieldSpecific(Block.java:111)
    at rubyjit.Celluloid::ThreadHandle$$initialize_07358B9DA40062DDC40C9968F3FFE7FE856FBB8C1216907342.chained_0_ensure_1$RUBY$__ensure__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:13)
    at rubyjit.Celluloid::ThreadHandle$$initialize_07358B9DA40062DDC40C9968F3FFE7FE856FBB8C1216907342.block_0$RUBY$__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:12)
    at rubyjit$Celluloid::ThreadHandle$$initialize_07358B9DA40062DDC40C9968F3FFE7FE856FBB8C1216907342$block_0$RUBY$__file__.call(rubyjit$Celluloid::ThreadHandle$$initialize_07358B9DA40062DDC40C9968F3FFE7FE856FBB8C1216907342$block_0$RUBY$__file__)
    at org.jruby.runtime.CompiledBlock19.yield(CompiledBlock19.java:159)
    at org.jruby.runtime.CompiledBlock19.call(CompiledBlock19.java:87)
    at org.jruby.runtime.Block.call(Block.java:101)
    at org.jruby.RubyProc.call(RubyProc.java:290)
    at org.jruby.RubyProc.call19(RubyProc.java:271)
    at org.jruby.RubyProc$INVOKER$i$0$0$call19.call(RubyProc$INVOKER$i$0$0$call19.gen)
    at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:202)
    at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:198)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:134)
    at rubyjit.Celluloid::InternalPool$$create_1BC69CCE201532A601035BFEBDC48D18CC83A46B1216907342.chained_1_rescue_2$RUBY$SYNTHETIC__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/internal_pool.rb:100)
    at rubyjit.Celluloid::InternalPool$$create_1BC69CCE201532A601035BFEBDC48D18CC83A46B1216907342.chained_0_rescue_1$RUBY$SYNTHETIC__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/internal_pool.rb:99)
    at rubyjit.Celluloid::InternalPool$$create_1BC69CCE201532A601035BFEBDC48D18CC83A46B1216907342.block_0$RUBY$__file__(<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/internal_pool.rb:98)
    at rubyjit$Celluloid::InternalPool$$create_1BC69CCE201532A601035BFEBDC48D18CC83A46B1216907342$block_0$RUBY$__file__.call(rubyjit$Celluloid::InternalPool$$create_1BC69CCE201532A601035BFEBDC48D18CC83A46B1216907342$block_0$RUBY$__file__)
    at org.jruby.runtime.CompiledBlock19.yield(CompiledBlock19.java:159)
    at org.jruby.runtime.CompiledBlock19.call(CompiledBlock19.java:87)
    at org.jruby.runtime.Block.call(Block.java:101)
    at org.jruby.RubyProc.call(RubyProc.java:290)
    at org.jruby.RubyProc.call(RubyProc.java:228)
    at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:99)
    at java.lang.Thread.run(Thread.java:722)

When printing stacktraces in ruby land I see this:

Thread TID-1x2g <app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks/task_fiber.rb:23:in `resume'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks/task_fiber.rb:23:in `deliver'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/tasks.rb:98:in `resume'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:412:in `task'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:321:in `handle_message'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:174:in `run'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/actor.rb:157:in `initialize'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:13:in `initialize'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:12:in `initialize'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/internal_pool.rb:100:in `call'
<app home>/shared/bundle/jruby/1.9/gems/celluloid-0.15.2/lib/celluloid/internal_pool.rb:100:in `create'

I'm seeing threads waiting around both Fiber#resume and Fiber.yield so it seems to be a problem with fibers. I'm not sure if this qualifies as a problem with Sidekiq or Celluloid, so I'm going to open issues in both projects. If there's any more information I can provide I would be glad to do so.

I discussed this with @headius and @cheald (Antiarc) on IRC. I also know that pooling of fibers has been reintroduced, though I don't believe has been released. I would be willing to try a dev / unstable release of jruby to test stuff out. Let me know if there's anything else I can do.

Owner

headius commented Feb 22, 2014

Yeah, this looks like the same stuff @cheald came to me with a few weeks ago. There were basically several situations where exceptions in the fiber did not propagate to the waiter, or vice versa...especially in the case of asynchronous exceptions from Timeout.

You can build jruby-1_7 branch and try that, or grab a nightly build from here: http://ci.jruby.org/snapshots/1.7.x/

I'm going to proactively mark this as closed, but let me know ASAP if you still have issues with 1.7.11.

@headius headius closed this Feb 22, 2014

@headius headius added this to the JRuby 1.7.11 milestone Feb 22, 2014

@headius headius added core labels Feb 22, 2014

@headius headius self-assigned this Feb 22, 2014

@headius I've been running the 1.7.11-SNAPSHOT for a few hours and the same problems seem to be present, let me know if there's any more diagnostic information I can provide.

Owner

headius commented Feb 24, 2014

Ok...can you confirm that you're running the .11 build? I just need to make absolutely sure you are still seeing hangs. We were due to release .11 today, but this will hold it up.

If you're positive it's actually running .11 (and maybe you should even try a master build incase our nightly has gotten behind) the next thing I'll need is a thread dump. Sent QUIT signal to process, hit ctrl+\ in the same console, or use the jstack command. Gist the result and attach it here.

@headius headius reopened this Feb 24, 2014

here's the full command running sidekiq, which appears to be using the 1.7.11 snapshot:

/usr/lib/jvm/default-java/bin/java -Xmx6g -Xms6g -Xss2048k -Djffi.boot.library.path=/usr/local/rbenv/versions/jruby-1.7.11-SNAPSHOT/lib/jni -XX:PermSize=1024m -XX:MaxPermSize=1024m -Djruby.reify.classes=true -server -Xbootclasspath/a:/usr/local/rbenv/versions/jruby-1.7.11-SNAPSHOT/lib/jruby.jar -classpath : -Djruby.home=/usr/local/rbenv/versions/jruby-1.7.11-SNAPSHOT -Djruby.lib=/usr/local/rbenv/versions/jruby-1.7.11-SNAPSHOT/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main <app home>/shared/bundle/jruby/1.9/bin/sidekiq -e production -C <app home>/current/config/sidekiq.yml -i 0 -P <app home>/current/tmp/pids/sidekiq.pid

here is a full thread dump (it's about 42k lines and 5MB, so be wary)
https://dl.dropboxusercontent.com/u/6475434/thread_dump

I can try building from master, are there instructions somewhere of how to do so? let me know if there's anything else I can provide.

when I built jruby from f87a497 it seems to work. I say seems because the log is moving quickly, but when I take a thread dump I still see ~93 / 182 threads in the WAITING state, though that might just be standard operating procedure.

Owner

headius commented Feb 24, 2014

Depending on how many fibers you have active over a period of time, you'll see some number of threads always alive but not doing anything (until they time out and are released from the pool).

It sounds like you're looking ok now and we can proceed with 1.7.11. I'll re-mark this fixed and hope you aren't seeing other issues :-)

@headius headius closed this Feb 24, 2014

it looks like I spoke too soon. the problem seems to take longer to present itself but is still there. I can provide another thread dump, but it looks very similar to the previous ones.

Owner

headius commented Feb 25, 2014

Ok, this looks like a new issue. I see all your many fiber threads, but none of them are blocked in the same way as for #1463. In that bug, fibers appeared to be stuck waiting for child fibers that would never return. I don't see that here. The fiber threads that I could see are either in the thread pool, waiting on epoll, waiting on a sleep, or waiting on a condition.

Further, the threads that are waiting on fibers roughly matches up with the fibers that I can see executing. So the waiting threads should eventually be yielded to by the fibers once they complete their epolls, sleeps, etc

I don't doubt that your appplication is hanging, but nothing in your original stack dump indicates to me that it's hanging because of a bug in Fiber. Reopening.

@headius headius reopened this Feb 25, 2014

@headius headius modified the milestones: JRuby 1.7.12, JRuby 1.7.11 Feb 25, 2014

So are you saying that the tasks that are RUNNABLE but are polling are holding up the threads that are in the WAITING state?

That makes sense to me except that some of the threads in WAITING seem to be originating from code like creating a new Celluloid actor or sending an actor a message. Perhaps there is a deadlock somewhere from mutexes that celluloid uses?

I know that celluloid sticks a lot of meta data as thread local variables, could that also cause problems?

Right now I'm mostly spitballing, but if you have any advice how to proceed further I would appreciate it.

@griffindy griffindy referenced this issue in celluloid/celluloid Feb 25, 2014

Closed

Celluloid actors slowly stopping #390

Owner

headius commented Feb 26, 2014

Someone who knows more about the internals of celluloid would be able to answer this better, but what I saw was that there were N threads in WATING state and just about N fibers mostly in RUNNING state, mostly waiting on nonblocking IO (epoll). There were a handful of fiber threads actually in WAITING states but those were either back in the thread pool, doing an explicit sleep (unsure what that's for), or waiting on a condition variable.

I very much appreciate you thinking on it. things for my application seem to have gotten better in the last few days for reasons unbeknownst to me. I seem to be getting about a 5 times longer life cycle before I have to restart it. I'm also going to try exploring switching out some libraries I use and see if the problem isn't there.

thanks again.

@enebo enebo modified the milestones: JRuby 1.7.13, JRuby 1.7.12 Apr 15, 2014

@enebo enebo modified the milestones: JRuby 1.7.14, JRuby 1.7.13 Jun 24, 2014

@enebo enebo modified the milestones: JRuby 1.7.14, JRuby 1.7.15 Aug 27, 2014

Owner

headius commented Nov 12, 2014

I was hoping to run celluloid tests on a more recent JRuby 1.7 (and 9k) but I can't seem to get them to work (bad gem versions in gemfile or something).

If it's possible for you to let us know how this bug has progressed, we'll know if there's more to fix.

Contributor

digitalextremist commented Jun 19, 2015

@headius I'm here with a variation of this problem in pure Celluloid ( no secondary libraries in use ) and the ability to adapt Celluloid per your advice. What exactly do you advise here?

We plan to implement a Multiplex in the future which might change some of the underlying issues exposed by this issue, but for now it'd be nice to resolve this without a new feature.

My version of this issue comes by expiration of a fiber handling an IO socket. I have a timeout wrapping socket handling, and when it expires, rather than being caught, the entire thread crashes with this:

#<Class:0x32b4ae5a>: execution expired
    org/jruby/ext/thread/Queue.java:152:in `pop'
    org/jruby/ext/thread/Queue.java:127:in `pop'
    org/jruby/ext/thread/SizedQueue.java:111:in `pop'
    org/jruby/ext/fiber/ThreadFiber.java:183:in `yield'
    org/jruby/ext/fiber/ThreadFiber.java:166:in `yield'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/task/fibered.rb:21:in `signal'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/task.rb:85:in `suspend'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/task.rb:24:in `suspend'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid.rb:143:in `suspend'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/call/sync.rb:41:in `response'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/call/sync.rb:45:in `value'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/proxy/sync.rb:40:in `method_missing'
    /home/de/.rvm/rubies/jruby-1.7.20/lib/ruby/1.9/forwardable.rb:201:in `debug'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/connection/handling.rb:32:in `process!'
    org/jruby/RubyKernel.java:1511:in `loop'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/connection/handling.rb:29:in `process!'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/connection/handling.rb:5:in `handle!'
    /home/de/.rvm/rubies/jruby-1.7.20/lib/ruby/1.9/forwardable.rb:201:in `handle!'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/connection/automata.rb:34:in `Automata'
    org/jruby/RubyBasicObject.java:1537:in `instance_eval'
    /home/de/.rvm/gems/jruby-1.7.20/gems/celluloid-fsm-0.9.0.pre13/lib/celluloid/fsm.rb:176:in `call'
    /home/de/.rvm/gems/jruby-1.7.20/gems/celluloid-fsm-0.9.0.pre13/lib/celluloid/fsm.rb:129:in `transition_with_callbacks!'
    /home/de/.rvm/gems/jruby-1.7.20/gems/celluloid-fsm-0.9.0.pre13/lib/celluloid/fsm.rb:97:in `transition'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/connection/automata.rb:29:in `Automata'
    org/jruby/RubyBasicObject.java:1537:in `instance_eval'
    /home/de/.rvm/gems/jruby-1.7.20/gems/celluloid-fsm-0.9.0.pre13/lib/celluloid/fsm.rb:176:in `call'
    /home/de/.rvm/gems/jruby-1.7.20/gems/celluloid-fsm-0.9.0.pre13/lib/celluloid/fsm.rb:129:in `transition_with_callbacks!'
    /home/de/.rvm/gems/jruby-1.7.20/gems/celluloid-fsm-0.9.0.pre13/lib/celluloid/fsm.rb:97:in `transition'
    /home/de/.rvm/rubies/jruby-1.7.20/lib/ruby/1.9/forwardable.rb:201:in `transition'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/connection.rb:15:in `initialize'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/handler.rb:8:in `serve'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp.rb:19:in `protection'
    org/jruby/ext/timeout/Timeout.java:126:in `timeout'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp.rb:19:in `protection'
    /data/code/intertune/celluloid-smtp/lib/celluloid/smtp/handler.rb:7:in `serve'
    org/jruby/RubyKernel.java:1962:in `public_send'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/calls.rb:28:in `dispatch'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/call/async.rb:7:in `dispatch'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/cell.rb:50:in `dispatch'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/cell.rb:76:in `task'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/actor.rb:363:in `task'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/task.rb:57:in `initialize'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/task.rb:47:in `initialize'
    /home/de/.rvm/gems/jruby-1.7.20/bundler/gems/celluloid-95f62fb7868c/lib/celluloid/task/fibered.rb:14:in `create'

That is happening with 1.7.20

Contributor

digitalextremist commented Jun 19, 2015

By the way, I work around this right now by executing my operation within its own Thread ... but within a Celluloid context, that's probably going to cause its own problem. For now it's sort of working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment