search

brandonhilkert / sucker_punch

Sucker Punch is a Ruby asynchronous processing library using concurrent-ruby, heavily influenced by Sidekiq and girl_friday.
MIT License
2.65k stars 114 forks source link

Long running jobs and unicorn timeout (a question) #111

Closed openface closed 9 years ago

openface commented 9 years ago

Let's say my unicorn timeout is set to 30 seconds.

I have an asynchronous sucker_punch job that takes 45 seconds to complete. Since this job is being run in a separate thread, my understanding is that once the request is processed, the unicorn worker is then freed up to process the next request. (thus, reseting the unicorn worker elapsed time)

So Unicorn will not terminate the worker that initiated the slow-running job, even though the job exceeds the timeout period.

Is my understanding correct? Thanks in advance.

brandonhilkert commented 9 years ago

Yup, that's correct.

On Sunday, April 12, 2015, Jason Hines notifications@github.com wrote:

Let's say my unicorn timeout is set to 30 seconds.

I have an asynchronous sucker_punch job that takes 45 seconds to complete. Since this job is being run in a separate thread, my understanding is that the unicorn worker process is complete, and is freed up to process the next request. (thus, reseting the unicorn worker time)

In other words, Unicorn will not terminate the worker that initiated the slow-running job, even though the job exceeds the timeout period.

Is my understanding correct? Thanks in advance.

— Reply to this email directly or view it on GitHub https://github.com/brandonhilkert/sucker_punch/issues/111.

_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

openface commented 9 years ago

Excellent, and thank you for this gem.

johnae commented 8 years ago

Is this actually true though? Ruby can't do real threads, only blocking IO activity frees up other threads for work. If you're doing lots of computation in ruby wouldn't that actually result in the unicorn worker being killed by the master since it can't respond to requests...