[
https://issues.apache.org/jira/browse/PHOENIX-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074869#comment-17074869
]
Mingliang Liu commented on PHOENIX-5812:
----------------------------------------
[~dbwong] and [~ckulkarni]
I prefer last interaction time to connection open time. Tracking a connection's
last interaction time seems not a big piece work (see the break down above),
correct me if I'm wrong. Instead, it is kind of destructive if we use the
connection open time + {{phoenix.connection.lifetime}} for checking. Connection
being closed off-band will need client side handling logic like retry. However,
such logic may have not been there if they treat connection being closed
off-band as a fatal exception. I'm not entirely sure how many use cases use
mid-/long-running connections. If they are believed minor use cases, I guess we
can start with connection open time and switch to last interaction time later.
For the second point, monitor vs doing this at throttle time, I agree with
[~dbwong]. I discussed with [~pawan.prakash] offline and his concern is more
about some "idle" connections being closed unnecessarily when the overall load
is relatively light. For e.g. there are only 10 long/idle connections, big
deal, why closing them? To address that, closing at throttle time and Phoenix
retrying internally would solve, but I'm think this adds more complexity. This
concern can be addressed if we support finer configurability in the monitor
(aka task of {{ScheduledExecutorService}} per CQS in above breakdown): minimum
number of connections to reap idle connections. If total number of connections
is smaller than that threshold (say 10), no connection gets auto-closed at all.
The implementation is incremental to this feature. However, I don't think we
need this level of control for starters, specifically not required by this
umbrella JIRA. It can be a follow up task, only if required.
Last, I still think we can expose the connection closing functionality with
more generic API, be it {{closeConnectionIf(Predicate)}} instead of
-{{closeAllIdleConnections()}}- . So other use cases can also use this. I will
post my idea of potentially close connections off-band for failover use case
shortly in a new Jira and link here, which can call this API as well.
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)
