I've got a big project running on MRI Ruby and Rails 3.2 on Passenger with an app that was not designed with thread-safety in mind and this app handles mailings through DelayedJob and the database is paying a heavy price for this.

Some possible problems are mentioned in the sidekiq railscast http://railscasts.com/episodes/366-sidekiq including:

  1. database connection limit (if using thread-pool of 1, the db connection limit should be doubled)
  2. thread-safety (this is probably the show stopper)
  3. fiber-safety? Is this an issue with AR?

So, the question are:

  1. how viable is it to make a big project thread-safe enough for the mail generation to work in threads inside the passenger process? (mailings are complex enough to depend on AR)
  2. same question when using sidekiq, "how viable is it to make a big project thread-safe enough for the mail generation to work using sidekiq? (mailings are complex enough to depend on AR)"
  3. apart from db connection limit and thread-safety issues, is there anything else to consider or less obvious got'chas I failed to forsee?
1

There are 1 answers

5
phoet On

I think that you are mixing up some stuff here.

I never used sidekiq, but I don't think that you have to turn on thread_safe! in your Rails application to use it.

AFAIK this is just for the request-processing to have a lock, or no lock in thread_safe! mode, so the Rails process can handle multiple requests in parallel.

When using sidekiq, that should not be one of your concerns. Just your E-Mail-Processing code needs to be thread-safe. Only the project maintainer can answer that question though.