On Tue, Mar 2, 2021 at 12:30 PM Armin Wurzinger <[email protected]> wrote:
> Am 02.03.2021 20:35, schrieb Jeremy Evans: > > On Tue, Mar 2, 2021 at 10:24 AM armin <[email protected]> wrote: > > Hello! > > > I have a hanami 1.3 app, but the issue should be unrelated to hanami. I > want to connect to a second db with plain Sequel-gem. Therefore I define > the connection in hanami's `config/environment.rb`, which is required in > `config/puma.rb`: > > ```ruby > # config/environment.rb > # ... > DWH = Sequel.connect(ENV['DWH'], :loggers => [Logger.new($stdout)]) > #... > ``` > In production I have a puma-config like that: > > ```ruby > # config/puma.rb > require_relative './environment' > workers 5 > > threads_count = 1 > threads threads_count, threads_count > > daemonize true > > preload_app! > > rackup DefaultRackup > port 2300 > environment 'production' > > before_fork do > DWH.disconnect > end > > on_worker_boot do > Hanami.boot > end > ``` > I used the `before_fork` hook to disconnect the db ( > http://sequel.jeremyevans.net/rdoc/files/doc/fork_safety_rdoc.html). But > after some time I get errors like that: > > ```txt > Sequel::DatabaseDisconnectError: PG::UnableToSend: SSL SYSCALL error: EOF > detected > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:166:in > `async_exec' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:166:in > `block in execute_query' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/database/logging.rb:49:in > `log_connection_yield' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:166:in > `execute_query' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:153:in > `block in execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:129:in > `check_disconnect_errors' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:153:in > `execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:515:in > `_execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:327:in > `block (2 levels) in execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:537:in > `check_database_errors' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:327:in > `block in execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/database/connecting.rb:301:in > `block in synchronize' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/connection_pool/threaded.rb:107:in > `hold' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/database/connecting.rb:301:in > `synchronize' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:327:in > `execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:1135:in > `execute' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/adapters/postgres.rb:680:in > `fetch_rows' > > > /home/usr/vendor/bundle/ruby/2.6.0/gems/sequel-4.49.0/lib/sequel/dataset/actions.rb:155:in > `each' > /home/usr/app/lib/repositories/dwh_repository.rb:39:in `to_a' > ``` > Maybe somebody can help and has a hint or an idea, what's the reason for > the SequelDatabaseDisconnectError. > > > The application lost connection to the database. When this happens, a > DatabaseDisconnectError is raised and Sequel removes the connection from > the connection pool. New connection will be created as needed up to the > maximum pool size. This is expected behavior. > > The best course of action is to fix your setup so your database does not > drop application connections. However, if that is not possible, you can > try the connection_validator extension, which can check connections before > use and automatically get a new connection if an existing connection is > bad, without the user seeing an error. > > Thanks, > Jeremy > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sequel-talk" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sequel-talk/AZ9tWBV9ON4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sequel-talk/CADGZSSfOQY0Fwz9FsvDHGAQd_eDFvNBFyQXgDySwb6kXg%3DJVzQ%40mail.gmail.com > <https://groups.google.com/d/msgid/sequel-talk/CADGZSSfOQY0Fwz9FsvDHGAQd_eDFvNBFyQXgDySwb6kXg%3DJVzQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > Which setup do you mean? What can be the reason, that my DB drops the > connection? Timeout? > Fix whatever is causing the connection to drop. Could be a database setting, firewall setting, etc.. In general, if you can avoid the disconnects happening in the first place, then you don't need to worry about how to handle them. It's only if there is nothing you can do and disconnects will happen anyway that you need something like the connection_validator extension. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/CADGZSSemS4aN%3D7iLKw_YdFj_aT4Hf3Q%2Byp9wQO2REsZp%3DF5qBw%40mail.gmail.com.
