@aelliott: I finally had a chance to play around with this, but I cannot seem to reproduce a bug. That said, let me describe what the expected behavior is, and you can tell me if this is what you expect and also if I'm describing something relevant to your issue.
When you set cache=X (where X is a non-negative integer or false ) on a SearchManager, it has the following effects:
When a search job is going to be created (e.g. when the query change), then we will first look to see if there is a previous search job that matches all the properties. If there is one, then we will look to see if it is "fresh" enough, where "fresh" is defined as the job being created less than X seconds ago (if it is a non-negative integer) or any job (if X===true ). If X===false , we will always create a new job. For SavedSearchManagers we also have the cache="cached" option, which just says to look for previously scheduled instances of this saved search.
If cache is "turned on", then we will never automatically cancel the search job. Usually, we will cancel the search job in two cases: (a) if a new search job needs to be created (e.g. when the query changes), or (b) if you navigate away from the page (if the search is complete). When caching is turned on, we do not do either of these. The reason is relatively simple: imagine you have a dashboard with a cached search, and you load the dashboard in two tabs (or two different users load it). Both of them will load the same search job, and if we cause a cancellation of the search, we've suddenly created a jarring experience for one of the tabs/users.
Given that, it makes sense that when a real time search is set with cache=True we will not cancel it on page navigation (or even when the search changes). In reality, for real time searches, we do not cancel them altogether, as they are never 'done'. Note that even the main search page (in the search app) does not cancel real time searches (it pauses them).
In your above sample code, if you change the the cache=120 to cache=False , you'll notice that when you change it to a real time search and then back to a non-realtime search, the real time search is cancelled. However, on page navigation, the search will continue running (per the notes above).
Finally, I've included below the full test page I used. It's very possible I misunderstood your issue, and if so, just let me know and we can re-work through it. Let me know if you have any other questions, and thank you for the feedback!
{% extends "splunkdj:base_with_app_bar.html" %}
{% load splunkmvc %}
{% block title %}Itay's Test Page{% endblock title %}
{% block css %}
<link rel="stylesheet" type="text/css" href="{{STATIC_URL}}splunkjs/css/dashboard.css" />
{% endblock css %}
{% block content %}
<div class="dashboard-body container-fluid main-section-body">
<div class="row">
<div class="span12 dashboard-header clearfix">
<h2>Test Page</h2>
</div>
</div>
<div class="dashboard-row">
<div class="dashboard-cell" style="width: 100%;">
<div class="dashboard-panel">
<div class="dashboard-element">
<div class="panel-head">
</div>
<div class="panel-body">
{% timerange id="activitysummary-timerange" preset="Last 30 days" %}
{% chart
id="sizesegment-piechart" managerid="sizesegment-piechart-search"
drilldown="all"
drilldownRedirect=False
resizable=True
type="pie"
%}
</div>
</div>
</div>
</div>
</div>
</div>
{% endblock content %}
{% block managers %}
{% searchmanager
autotstart=True
id="sizesegment-piechart-search"
search="index=_internal | head 1000 | top limit=10 sourcetype"|token_safe
preview=True cache=120 %}
{% endblock managers %}
{% block js %}
<script>
require(["splunkjs/ready!"], function(mvc) {
var timerange = mvc.Components.get("activitysummary-timerange");
var manager = mvc.Components.get("sizesegment-piechart-search");
timerange.on("change", function () {
manager.search.set(timerange.val());
});
})
</script>
{% endblock js %}
... View more
