-
Notifications
You must be signed in to change notification settings - Fork 419
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.
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
Thread pools behaving oddly with max_queue
and remaining_capacity
#684
Comments
May I bump this question again? We'd really need a solution for this and are kind of stuck. Thanks a lot for having a quick look at this and sorry for bothering you again. |
Sorry, I did not have free time left and could not attend concurrent-ruby for a while. Unfortunately the thread-pool uses What's you use case for this requirement, if you don't mind me asking? I may be able to suggest alternative approach. |
Thanks a lot for your answer. The reason for this requirement is the Gem workhorse. It has a (concurrent-ruby) queue of jobs and regularly polls the database for new jobs, only fetching as many jobs as the queue can still handle. So for instance, if we have a queue size of 5 and 3 jobs are active, the poller only fetches 2 jobs from the database. To work around this issue, we've now created a wrapper around the |
@remofritzsche If you are looking to determine how many threads are available in the pool, you can apply the following patch to concurrent-ruby:
Then just replace pool.remaining_capacity with pool.ready_worker_count in your example (and set max_queue to -1 instead of 0) and you will achieve the desired behaviour. |
Great, thank you. Are there any plans of adding this to the official source? As we're developing a Gem, we do not want to patch other Gems if we can work around it. Thanks :) |
I think the correct way to have no queue (e.g. run the fallback if all threads are active) is to use Concurrent::ThreadPoolExecutor.new(max_queue: 0, synchronous: true)` You can see this behavior is asserted in the tests:
And this is the implementation in Ruby: concurrent-ruby/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb Lines 208 to 213 in 9f40827
|
We're in need for a thread pool that has a maximum number of parallel threads, no queue and fails if too many threads are added. We also need to be able to detect how many threads are "free" at a given time.
We've tried almost all of the ThreadPool and ThreadPoolExecutor classes but can't get it to work:
If we interpret the documentation right, this should create a thread pool with 0 threads at start that can grow up to 5 threads which are handled in parallel. If all 5 threads are occupied, posting new work units should result in an exception. There should be no additional queue. We'd also expect
remaining_capacity
to drop by 1 each time something has been posted and the previous threads are still busy.The output of the above script:
Expected would be:
Did we interpret the documentation wrong and how can we achieve what we need? We're also need to be able to detect the number of idle threads so that we can post the right number of work units to it.
On a side-note: The above example stops with a number of exceptions like the following:
I have currently no idea what this is about. But this second problem does not happen in our application and is not a dealbreaker.
Thanks a bunch for having a look at the first question though - this would help us a lot. Keep up your wonderful work!
concurrent-ruby
version: 1.0.5concurrent-ruby-ext
installed: noconcurrent-ruby-edge
used: noThe text was updated successfully, but these errors were encountered: