[
https://issues.apache.org/jira/browse/SENTRY-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Spector updated SENTRY-1866:
----------------------------------
Description:
Motivation: can think of several, but the immediate ones are:
a) logging Sentry server unavailability on client side. With multiple active
connections to Sentry server, logging each failed RPC call (currently at DEBUG
level) at the INFO level to the same Sentry server that went down can be way
too verbose and redundant. It can also be misleading, because there is no
mandatory link between when connection was established and when an attempt to
use it has failed, so we can report failures of the old, stale, connections.
b) enabling optimization of connection pooling. Ping RPC call would most likely
fail due to server inavailability (crash, restart ..), so it can be temporarily
marked as unavailable, so no new connection attempts are made within some
configurable time interval (say, 1 sec).
was:
Motivation: can think of several, but the immediate ones are:
a) logging Sentry server unavailability on client side. With multiple active
connections to Sentry server, logging each failed RPC call (currently at DEBUG
level) at the INFO level to the same Sentry server that went down can be way
too verbose and redundant. It can also be misleading, because there is no
mandatory link between when connection was established and when an attempt to
use it has failed, so we can report failures of the old connections.
b) enabling optimization of connection pooling. Ping RPC call would most likely
fail due to server inavailability (crash, restart ..), so it can be temporarily
marked as unavailable, so no new connection attempts are made within some
configurable time interval (say, 1 sec).
> Add ping Thrift APIs for Sentry services
> ----------------------------------------
>
> Key: SENTRY-1866
> URL: https://issues.apache.org/jira/browse/SENTRY-1866
> Project: Sentry
> Issue Type: Improvement
> Reporter: Vadim Spector
>
> Motivation: can think of several, but the immediate ones are:
> a) logging Sentry server unavailability on client side. With multiple active
> connections to Sentry server, logging each failed RPC call (currently at
> DEBUG level) at the INFO level to the same Sentry server that went down can
> be way too verbose and redundant. It can also be misleading, because there is
> no mandatory link between when connection was established and when an attempt
> to use it has failed, so we can report failures of the old, stale,
> connections.
> b) enabling optimization of connection pooling. Ping RPC call would most
> likely fail due to server inavailability (crash, restart ..), so it can be
> temporarily marked as unavailable, so no new connection attempts are made
> within some configurable time interval (say, 1 sec).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
