On Tuesday, March 31, 2020 at 5:02:15 AM UTC-7, BeeRich33 wrote:
>
> Yes I've read the documentation several times and it is unclear.
>
> "Before checkout" isn't evident and leads me to believe it's at the end of
> a connection. Why it would check the connection pool at the end of a
> connection is strange as I would expect the flushing of the pool would
> occur at the onset of a demand of a connection, regardless if the pool has
> valid open connections or not. This is why I'm confused.
>
You checkout a connection from the pool for use. Connection checkout
happens when a connection is needed, connection checkin happens when the
connection is no longer needed. I guess the documentation does not
explicitly define that, but nobody else has expressed confusion regarding
it.
> Just now, bringing up the page again after 8 hours (which is over the
> stated default value of 1 hour), it happened again. So the syntax I have
> in there, directly after the declaration of that constant (Sequel::Database
> connection), wouldn't it check the pool only to find no valid live
> connections. Would it see the pool as empty and initiate a new
> connection?
>
You should run it with a database logger, and log the connection info. If
the time between when the connection was last checked in and when it is
being checked out is more than connection_validation_timeout, it will send
a query to the database. If the query fails, the connection is not valid
and will be removed, and a new connection will be made (or another
available connection used if there is one).
At this point I'm thinking these errors are from entries in the pool that
> are not open anymore. And I thought the syntax provided would have flushed
> the pool upon a morning entry (my example internal website serves me only,
> so it's idle overnight). The last request at the end of the day would
> update the single connection in the pool. One hour later, it expires (or
> is considered expired by Sequel's default value). It will eventually
> close, as is shown by the error. I am under the impression that this is
> used at the beginning of a new session in the morning, hence the placement
> right behind the declaration. I'm not clear on what I'm missing. This
> isn't about < 60 minutes vs > 60 minutes. This is showing up on something
> 10 hours idle.
>
Well, without seeing your code, I have no idea what is going wrong. If
you want an example of how it works:
With this code:
DB.extension :connection_validator
DB.pool.connection_validation_timeout = -1
DB.log_connection_info = true
p DB.get(1)
# Drop the connection socket:
/([\d.]+:\d+) --> ([\d.]+:\d+)/ =~ `fstat -n | fgrep 5432`
system('tcpdrop', $1, $2)
p DB.get(1)
Output:
I, [2020-03-31T08:56:57.970824 #78153] INFO -- : (0.000614s) (conn:
3281240512840) SELECT NULL
I, [2020-03-31T08:56:57.972597 #78153] INFO -- : (0.001657s) (conn:
3281240512840) SELECT 1 AS "v" LIMIT 1
1
E, [2020-03-31T08:57:46.881587 #78153] ERROR -- : PG::ConnectionBad:
PQconsumeInput() could not receive data from server: Software caused
connection abort: (conn: 3281240512840) SELECT NULL
I, [2020-03-31T08:57:46.896685 #78153] INFO -- : (0.000647s) (conn:
3279908498200) SET standard_conforming_strings = ON
I, [2020-03-31T08:57:46.897196 #78153] INFO -- : (0.000416s) (conn:
3279908498200) SET client_min_messages = 'WARNING'
I, [2020-03-31T08:57:46.897581 #78153] INFO -- : (0.000305s) (conn:
3279908498200) SET DateStyle = 'ISO'
I, [2020-03-31T08:57:46.899019 #78153] INFO -- : (0.001331s) (conn:
3279908498200) SELECT 1 AS "v" LIMIT 1
1
Notice how the log shows the error was raised by the connection that was
dropped, then a new connection was made and the correct value returned
without raising an exception to the user. In other words, replacing the
invalid connection was handled transparently.
If you still think this is a problem with the connection_validator
extension, please provide a minimal self contained example of the problem
you having, as well as a database log with connection info, so that I can
review and test it.
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 sequel-talk+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sequel-talk/8e8f0181-79d0-4ab1-b726-b196944da629%40googlegroups.com.
