On Wednesday, April 15, 2020 at 7:23:50 PM UTC-4, Jeremy Evans wrote:
>
> On Wednesday, April 15, 2020 at 2:52:23 PM UTC-7, BeeRich33 wrote:
>>
>> OK, I'm finding that disconnection times vary between < 1 second and 5
>> minutes.
>>
>> disconnection: session time: 0:03:35.335 user=rich database=alpha
>> host=localhost port=51523
>>
>>
> Does this output indicate that after you disconnect the connection (kill
> the socket), Sequel takes that long to handle the disconnection, or
> something else? I'm not sure what this disconnect time represents.
>
This is separate. I got the loggers going with *connection* and
*discconnection* log entries, and they were happening quicker than I had
expected. I couldn't find anything direct or quick to manually kill open
sockets. I assumed these disconnections would suffice.
I came back after some time and found another:
2020-04-15 19:19:27.865 EDT [17917] LOG: disconnection: session time: 3:17:
36.711 user=rich database=alpha host=[local]
So over 3 hours, but for [local], not localhost. Here's another connection
that started up for some reason, then disappeared. I don't know what
instantiated it. I have crontabs working but this doesn't seem like one of
them.
2020-04-15 17:32:02.843 EDT [23811] LOG: connection received:
host=localhost port=51548
2020-04-15 17:32:02.844 EDT [23811] LOG: connection authorized: user=rich
database=alpha
2020-04-15 17:32:02.848 EDT [23811] LOG: statement: SET
standard_conforming_strings = ON
2020-04-15 17:32:02.849 EDT [23811] LOG: statement: SET
client_min_messages = 'WARNING'
2020-04-15 17:32:02.850 EDT [23811] LOG: statement: SET DateStyle = 'ISO'
2020-04-15 17:32:07.869 EDT [23811] LOG: statement: SELECT
CAST(current_setting('server_version_num') AS integer) AS v
2020-04-15 17:37:01.235 EDT [23811] LOG: disconnection: session time:
0:04:58.392 user=rich database=alpha host=localhost port=51548
I'm saying that if you choose a number above 0, the connection_validator
> extension will skip validation on checkout if the connection was checked in
> fewer than that many seconds ago. If you want to validate on every
> checkout, regardless of the time since checkin, then you would use a number
> less than 0. The connection_validator extension does not validate on every
> checkout by default as validation has a performance cost, and the more
> recently the connection was checked in, the less likely it is to be invalid.
>
Ok. I get that. I collected the following range (sorted) since I started
the logs:
0:00:00.015
0:00:00.022
0:00:00.027
0:00:00.041
0:00:00.057
0:00:05.068
0:00:05.071
0:00:05.073
0:00:05.213
0:00:05.298
0:00:05.307
0:00:05.317
0:00:07.324
0:00:27.537
0:00:28.004
0:00:34.885
0:01:06.986
0:01:14.123
0:01:17.118
0:01:17.441
0:01:49.220
0:02:29.014
0:02:46.310
0:03:35.335
0:03:48.472
0:03:48.631
0:03:52.094
0:04:58.024
0:04:58.322
0:04:58.392
0:04:58.402
0:04:58.404
0:04:58.451
0:04:58.493
0:04:58.582
So when I was getting first attempt connection errors, with no
connection_validation, It wasn't checking the pool, and could either have
had inactive valid connections, or no connections at all. Either case
would have resulted in a connection. I was getting errors though. That's
where I'm confused.
I can set it to 6 seconds, which in this small sample set, covers 12 of the
35 entries.
> If you think there is an issue here, please put together a minimal, self
> contained example similar to the one I posted earlier. I can then review
> that to determine if there is a problem, and if so, hopefully how to fix it.
>
No issue, just my understanding of how it's working and how I should
implement it. The very reason I came to Sequel from using the PG gem as an
ORM, was database connections.
Theoretically, with shorter *DB.pool.connection_validation_timeout* values,
the more connectors are instantiated, ultimately, instead of connectors to
become available.
Cheers
--
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/916888f6-d218-488e-af17-0d9641ecbc35%40googlegroups.com.
