Robert Nettleton created AMBARI-19658:
-----------------------------------------
Summary: LogSearch Integration Cache Timeout should be configurable
Key: AMBARI-19658
URL: https://issues.apache.org/jira/browse/AMBARI-19658
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Nettleton
Assignee: Robert Nettleton
Priority: Critical
Fix For: 2.5.0
In Ambari 2.4.0, during the initial integration with LogSearch, a cache was
implemented to reduce the number of calls to the LogSearch service when the
PropertyProvider implementation for LogSearch integration is called in other
contexts (such as Rolling/Express Upgrades, REST API calls on the HostComponent
resource, etc).
That cache was implemented in the following class:
{code}
org.apache.ambari.server.controller.logging.LogSearchDataRetrievalService
{code}
In the initial implementation, the cache was hard-coded to expire within in
hour.
In
org.apache.ambari.server.controller.logging.LogSearchDataRetrievalService#doStart:
{code}
protected void doStart() {
LOG.debug("Initializing caches");
// initialize the log file name cache
logFileNameCache = CacheBuilder.newBuilder().expireAfterWrite(1,
TimeUnit.HOURS).build();
// initialize the log file tail URI cache
logFileTailURICache = CacheBuilder.newBuilder().expireAfterWrite(1,
TimeUnit.HOURS).build();
// initialize the Executor
executor = Executors.newSingleThreadExecutor();
}
{code}
An hour is probably too short of an interval, since the cache data is unlikely
to change often. This timeout should be a configurable option in the Ambari
LogSearch Integration code.
1. The default timeout should be much larger, as this information obtained from
the LogSearch service is generally static. We should increase the timeout to
be at least 24 hours, or perhaps move to an unbounded timeout, provided that
the timeout would be configurable.
2. The max timeout for the cache should be configurable in ambari.properties,
with a reasonable default if not set (as mentioned above).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)