Skip to content

Commit

Permalink
FIX: properly spin down unused streamer threads
Browse files Browse the repository at this point in the history
Previous version was prone to the bug:

ruby-concurrency/concurrent-ruby#1075

This is particularly bad cause we could have a DB connection
attached to the thread and we never clear it up, so after N hours
this could start exhibiting weird connection issues.
  • Loading branch information
SamSaffron committed Dec 20, 2024
1 parent a4033e2 commit 1000549
Showing 1 changed file with 7 additions and 9 deletions.
16 changes: 7 additions & 9 deletions lib/ai_bot/response_http_streamer.rb
Original file line number Diff line number Diff line change
Expand Up @@ -8,21 +8,19 @@ class ResponseHttpStreamer

class << self
def thread_pool
# we use our thread pool implementation here for a few reasons:
#
# 1. Free multisite support
# 2. Unlike Concurrent::CachedThreadPool, we spin back down to 0 threads automatiaclly see: https://github.com/ruby-concurrency/concurrent-ruby/issues/1075
# 3. Better internal error handling
@thread_pool ||=
Concurrent::CachedThreadPool.new(min_threads: 0, max_threads: POOL_SIZE, idletime: 30)
Scheduler::ThreadPool.new(min_threads: 0, max_threads: POOL_SIZE, idle_time: 30)
end

def schedule_block(&block)
# think about a better way to handle cross thread connections
if Rails.env.test?
block.call
return
end

db = RailsMultisite::ConnectionManagement.current_db
thread_pool.post do
begin
RailsMultisite::ConnectionManagement.with_connection(db) { block.call }
block.call
rescue StandardError => e
Discourse.warn_exception(e, message: "Discourse AI: Unable to stream reply")
end
Expand Down

0 comments on commit 1000549

Please sign in to comment.