[
https://issues.apache.org/jira/browse/PHOENIX-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077859#comment-17077859
]
Mingliang Liu commented on PHOENIX-5812:
----------------------------------------
[~jisaac] and [~stoty]
How to define more crisply last accessed/interaction time is not very
straightforward to me. That's a very valid question since user would need to
understand this before they set the lifetime parameter. I think it's fine to
simply track the coarse granularity of connection interaction and do not track
the long-running result iteration/mutation. More accurate tracking can be done
with best effort, but basic interaction time is still way better than
connection open time.
I agree we should include PQS into the discussion. For starters, could we
simply disable this feature on PQS? The motivation here is to protect from
leaked connections, and it seems PQS is already offering that with the
connectionCache in Meta. This by default will be disabled since: _1)_ each
connection has default infinite lifetime, and _2)_ no per connection lifecycle
[option|https://calcite.apache.org/avatica/docs/client_reference.html]
supported in the Avatica connection URL.
----
[~RichardAntal] and [~stoty]
I agree with [~stoty] that reaping connections with load-based TTL is not
free. The priority queue based solution would need to maintain the queue for
every operation of every connection. The reason is that, priority queue works
by putting new elements in the appropriate position when they are *inserted*.
Correct me if I'm wrong.
I also agree even load-based TTL is possible with some clever implementation, a
time based solution still adds value.
----
[~elserj] and [~RichardAntal]
I like the idea of least user facing mindset. For configuration, both per
connection lifetime property and config in Configuration (e.g.
`hbase-site.xml`) can be accepted. The monitor thread starts and schedules
automatically per CQSI so no user intervention is required. However users need
to retry their logic when their connections get closed too early. To avoid that
retry, we may have to support connection auto-open after close. I'm not sure we
need to go that far.
I get how it merits if HConnection can be automatically closed/re-created. That
however may not be implementation detail of this JIRA, and instead that is
largely orthogonal to how I would take this problem. The reason is I guess that
would change somehow the current model: one CQS per connection info, one
HConnection per CQS, and/or _M_ PConnection per CQS. Is that true?
Thanks,
> Automatically Close "Idle" Long Open Connections
> ------------------------------------------------
>
> Key: PHOENIX-5812
> URL: https://issues.apache.org/jira/browse/PHOENIX-5812
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Daniel Wong
> Priority: Major
>
> As Phoenix may keep a maximum default number of connections. Badly
> performing client calls or internal errors (See PHOENIX-5802). Can cause
> total available connections to go to 0. Proposing a client connection
> monitor with a connection reaper like task to reap idle connections.
> Definition of "Idle"
> Simple may be simple time based say if a connection has been open for
> configurable amount of minutes simply close.
> More complicated solution may be keeping track of last interaction time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
