[AMBARI-19658] LogSearch Integration Cache Timeout should be configurable

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.4.0
• Fix Version/s: 2.5.0
• Component/s: ambari-server
• Assignee: Bob Nettleton
• Reporter: Bob Nettleton
• Created: 20/Jan/17 20:42
• Updated: 25/Jan/17 00:57
• Resolved: 24/Jan/17 22:55

Description

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:

org.apache.ambari.server.controller.logging.LogSearchDataRetrievalService

In the initial implementation, the cache was hard-coded to expire within in hour.

In org.apache.ambari.server.controller.logging.LogSearchDataRetrievalService#doStart:

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();
  }

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).