Thanks a lot, Jeremy and James! I did the changes in my app and I'm monitoring to see if new exceptions will happen, so far so good. I oversaw these configurations.
On Tuesday, April 9, 2019 at 8:22:40 AM UTC+2, James Silberbauer wrote: > > > > On 2019/04/09 02:04, Jeremy Evans wrote: > > On Monday, April 8, 2019 at 1:22:48 PM UTC-7, James Silberbauer wrote: >> >> >> On 2019/04/08 20:51, Jeremy Evans wrote: >> >> On Monday, April 8, 2019 at 6:57:50 AM UTC-7, Gustavo Sobral wrote: >>> >>> Hi, >>> >>> I have a Sinatra app with Sequel and Postgres adapter running in a >>> Phusion Passenger server and I'm facing around 50~60 >>> Sequel::DatabaseDisconnectError exceptions a day. These exceptions have >>> mainly three messages on it: >>> >>> PG::UnableToSend: SSL error: decryption failed or bad record mac >>> PG::UnableToSend: SSL SYSCALL error: EOF detected >>> PG::UnableToSend: PQconsumeInput() SSL error: decryption failed or bad >>> record mac >>> >>> This is my file responsible for initializing Sequel, I've already tried >>> without success to use the connection_validation extension: >>> >>> # frozen_string_literal: true >>> >>> # TZ settings >>> Sequel.application_timezone = 'Amsterdam' >>> Sequel.database_timezone = :utc >>> >>> # Json serializer plugin >>> Sequel::Model.plugin :json_serializer >>> >>> # Global 'DB' handle is a Sequel convention >>> db_config = YAML.load_file(File.join(Dir.pwd, 'config/database.yml'))[ >>> ENV['RACK_ENV']] >>> DB = Sequel.connect(db_config) >>> >>> # Validate that connections checked out from the pool are still valid, >>> before yielding them for use >>> # >>> http://sequel.jeremyevans.net/rdoc-plugins/files/lib/sequel/extensions/connection_validator_rb.html >>> DB.extension(:connection_validator >>> DB.pool.connection_validation_timeout = -1 >>> >>> Can anybody shed some light what can possibly be going on here? I'm >>> using the free version of Phusion Passenger with single-threaded, >>> multi-processed concurrency model. >>> >> >> That does look like it should work. The only reason I think it wouldn't >> is if the disconnects are happening on a connection that has been validated >> and already been checked out. In that case, there is nothing that Sequel >> can do about the issue. When the exception is raised, Sequel will remove >> the connection from the pool, so that a new connection can be established. >> You could try wrapping everything in a transaction and using the :retry_on >> option, but a better approach would be to find out why the disconnections >> are happening in the first place and fix them. >> >> Thanks, >> Jeremy >> >> >> Hi >> >> I have a similar issue which I have not yet been able to reproduce >> in-house. >> This is not exactly the same issue, but I mention it here as it may help >> in some way. >> >> This is a Roda app using Sequel which raises the exception: >> "Sequel::DatabaseDisconnectError: PG::ConnectionBad: PQconsumeInput() >> server closed the connection unexpectedly This probably means the server >> terminated abnormally before or while processing the request.". >> >> This only happens on servers that are running the app in Phusion >> Passenger. >> It also only seems to happen after using Capistrano to deploy the app. >> (probably because the deploy triggers a passenger reload-app call) >> The disconnect error will come up a short while after deploy and it will >> only happen once. >> Immediately after deploy I am able to interact with the app without >> triggering the exception, but some time later a different user will trigger >> the exception. >> >> The exception is always raised in the same place - for every request >> there is a check to see if the ip address is in a table which identifies >> certain devices by ip address. >> This is the first database query in all requests. >> >> This would appear to point to something going wrong when passenger >> reloads a stale process. >> I have not yet had time to try to reproduce this locally, so I don't have >> any further insight at this stage. >> > > Based on the reports, I think in both cases, this may be caused because > you didn't disconnect before forking. If you aren't manually issuing a > disconnect call before forking, and you are using preload_app, that is the > probable cause. > > See: > > > http://sequel.jeremyevans.net/rdoc/files/doc/code_order_rdoc.html#label-Disconnect+If+Using+Forking+Webserver+with+Code+Preloading > > > https://www.phusionpassenger.com/library/indepth/ruby/spawn_methods/#am-i-responsible-for-reestablishing-database-connections-after-the-preloader-has-forked-a-child-process > > Thanks, > Jeremy > > > Thank you Jeremy, I was not catering for this, so I'm pretty sure that's > the cause. > > -- > 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] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > Visit this group at https://groups.google.com/group/sequel-talk. > For more options, visit https://groups.google.com/d/optout. > > > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
