[
https://issues.apache.org/jira/browse/PHOENIX-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17078534#comment-17078534
]
Josh Elser commented on PHOENIX-5812:
-------------------------------------
bq. 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.
Well, PQS does have a time-bounded cache on Connections and Statements it will
hold onto in memory. However, these are different than the HConnection/CQSI
being held in PhoenixDriver (which is, I think, what we really care about
closing). I could also be mistaken and this may have changed already :). I
think any solution we come up with for applications could/should also apply to
PQS.
bq. 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.
This is exactly what I think would be too jarring. It's akin to breaking public
API -- it would require code to change for every downstream user. I also
recognize that it will make the implementation more challenging, but
simplifying how we do this connection caching is a very worthwhile pile of
string to unravel.
bq. 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?
Yeah, I think the crux is that we would eventually need a terminal case where a
CQS/HConnection is closed/reclaimed. This could be triggered by some mechanism
(e.g. reference counting, time-based, etc), but then, if an "old" PConn was
still being held onto by a client, we would want to re-create that CQS. The
trick, I think, would to be super careful around the code in
PhoenixEmbeddedDriver where we avoid creating too many CQS's. I suspect this is
a deep rabbit hole :)
> 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)
