[
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 benefits, 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.
While periodic pinging allows implementing a simple logic that reports server
becoming unavailable and then available again only once per occurrence.
b) enabling optimization of connection pooling. Ping RPC call would most likely
fail due to server unavailability (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). It can be a significant performance
improvement in high volume calls scenario.
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, stale, connections.
While periodic pinging allows implementing a simple logic that reports server
becoming unavailable and then available again only once per occurrence.
b) enabling optimization of connection pooling. Ping RPC call would most likely
fail due to server unavailability (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). It can be a significant performance
improvement in high volume calls scenario.
> 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 benefits, 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. While periodic pinging allows implementing a simple logic that
> reports server becoming unavailable and then available again only once per
> occurrence.
> b) enabling optimization of connection pooling. Ping RPC call would most
> likely fail due to server unavailability (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). It can be a significant
> performance improvement in high volume calls scenario.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
