Rails 4.x compatibility

[neongrau]

I just had the issue that on windows there only is threading and in lib/spawnling.rb in sel.frun there is a check for "allow_concurrency?" that fails and then the line
@@logger.error("spawn(:method=>:thread) only allowed when allow_concurrency=true")
fails because @@logger isn't there. So all i got was:

D:/Informer/ruby/lib/ruby/gems/2.0.0/gems/spawnling-2.1.3/lib/spawnling.rb:112:in run': undefined methoderror' for nil:NilClass (NoMethodError)

Then clean_connections failed at "verify_active_conenctions!" strangely so because i'd have expected the "respond_to?" check catching that.

I quickly monkey patched it this way:

class Spawnling
def self.allow_concurrency?
true
end
def self.clean_connections
ActiveRecord::Base.clear_active_connections!
end
end

But i guess you should check and set allow_concurreny true if rails >= 4.0.0.
And the clean_conenctions should somehow call the ConnecteionPool Reaper but i haven't yet figured out myself how to do that.

[mhuggins]

I was looking at this repo in consideration for a Rails 4 app as well. Is this something that might be fixed?

[mnoack]

@neongrau @mhuggins We currently use this on a rails 3 app, so we haven't gotten around to fixing it ourselves. I welcome any PR that passes the tests (and adds rails4 to the gemfiles folder and .travisci.yml).

[lesliev]

Spawnling doesn't work with Rails 4, I get errors like this in the code after the fork:
ActiveRecord::StatementInvalid: PG::ConnectionBad: PQconsumeInput() SSL connection has been closed unexpectedly

I've done a lot of reading and experimenting to try and fix Spawnling and the only thing that I've tried that's worked so far is something like this:

ActiveRecord::Base.connection.disconnect! if defined?(ActiveRecord)
fork do
  ActiveRecord::Base.establish_connection      # in patches.rb
  yield      # run code inside Spawnling.new{}
end
ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

This lets both the forked code and original code keep using Active Record without error, but I can't tell if it's leaking connections. Does anyone have a test for that?

ActiveRecord::Base.connection_pool.send(:current_connection_id) stays the same before, after and during the fork.

Much of what I read seems to be false with regards to using ConnectionPool. For example, using ActiveRecord::Base.connection_pool.with_connection { yield } seems to keep using the original connection - because code after the fork gives the PG error again. I am trying to fork, not Thread.new, so that might be an issue.

In any case I am going to move to a different queueing solution now, but I'm interested to know how all this is supposed to be done.

[qen]

i encounter a similar error but not in spawnling, but in delayed_job and
sometimes in passenger, the only clue i get is that the cause could be from
the pg gem version used, because i don't encounter this issue on my other
rails app, also worth mentioning is that this only happens on my
development laptop not on production

On Tue, Feb 9, 2016 at 10:27 AM, Leslie Viljoen notifications@github.com
wrote:

Spawnling doesn't work with Rails 4, I get errors like this in the code
after the fork:
ActiveRecord::StatementInvalid: PG::ConnectionBad: PQconsumeInput() SSL
connection has been closed unexpectedly

I've done a lot of reading and experimenting to try and fix Spawnling and
the only thing that I've tried that's worked so far is something like this:

ActiveRecord::Base.connection.disconnect! if defined?(ActiveRecord)
fork do
ActiveRecord::Base.establish_connection # in patches.rb
yield # run code inside Spawnling.new{}
end
ActiveRecord::Base.establish_connection if defined?(ActiveRecord)

This lets both the forked code and original code keep using Active Record
without error, but I can't tell if it's leaking connections. Does anyone
have a test for that?

ActiveRecord::Base.connection_pool.send(:current_connection_id) stays the
same before, after and during the fork.

Much of what I read seems to be false with regards to using
ConnectionPool. For example, using ActiveRecord::Base.connection_pool.with_connection
{ yield } seems to keep using the original connection - because code
after the fork gives the PG error again. I am trying to fork, not
Thread.new, so that might be an issue.

In any case I am going to move to a different queueing solution now, but
I'm interested to know how all this is supposed to be done.

—
Reply to this email directly or view it on GitHub
#53 (comment).

“I know that you believe you understand what you think I said, but I'm not
sure you realize that what you heard is not what I meant.” –Richard Nixon

[neongrau]

Since i've upgraded from Rails 3 to 4.x i'm too having unexplainable DB issues (disconnects, hangs due to no more connections available). When cranking up the the pool size in database.yml this gets fairly rare. But still occurs way too often for my taste (in production mainly).

I've tried wrapping ActiveRecord::Base.connection_pool.with_connection { yield } blocks around anything where spawnling is used but that never really helped to get rid of the problem.

[mnoack]

Hi guys, we no longer use spawnling in our work, we stopped using it during a rails 3 app, so we honestly won't be maintaining it anymore, BUT I'm happy for some of you to take on the role of maintaining the gem (it's hardly a big complex gem like many others to maintain).

I will continue to review and merge PR's as they come in and I look forward to someone solving this rails 4 issue in a PR.

[mnoack]

Closing as this issue is stale. I note the code does pass in the rails 4 branch, but that the tests (at least at the time of this issue) were not covering this issue.

I'm still happy to accept PR's to address any outstanding issues.

Thanks