<p dir="auto">A standard GET by ID results in a single log entry in the audit log. Search (_search) results in two identical log entries. Every time.</p>
<ul dir="auto">
<li>Default ES 1.6.0 installation.</li>
<li>Added latest Shield.</li>
<li>Added "search_admin" user.</li>
</ul>
<p dir="auto">Everything works great out of the box except I get _search audits duplicated in the log. ONLY "SearchRequest" audits. I haven't found any other api yet which results in this strange behavior.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="[2015-06-16 18:37:24,705] [esdev-shieldpoc01] [transport] [access_granted]      origin_type=[rest], origin_address=[/10.30.24.36:55308], principal=[search_admin], action=[indices:data/read/search], indices=[test], request=[SearchRequest]
[2015-06-16 18:37:24,705] [esdev-shieldpoc01] [transport] [access_granted]      origin_type=[rest], origin_address=[/10.30.24.36:55308], principal=[search_admin], action=[indices:data/read/search], indices=[test], request=[SearchRequest]"><pre class="notranslate"><code class="notranslate">[2015-06-16 18:37:24,705] [esdev-shieldpoc01] [transport] [access_granted]      origin_type=[rest], origin_address=[/10.30.24.36:55308], principal=[search_admin], action=[indices:data/read/search], indices=[test], request=[SearchRequest]
[2015-06-16 18:37:24,705] [esdev-shieldpoc01] [transport] [access_granted]      origin_type=[rest], origin_address=[/10.30.24.36:55308], principal=[search_admin], action=[indices:data/read/search], indices=[test], request=[SearchRequest]
</code></pre></div>
<p dir="auto">Hi,</p>
<p dir="auto">I've been using ES for about a month now on a 6-node cluster.  There are a few issues ES exhibits when coming up from a failed-node or failed-cluster scenario.  These are pretty major, IMHO, because they result in longer downtime than is absolutely necessary.</p>
<p dir="auto">Please forgive me if this is a duplicate issue.  I'm dealing with ES recovery as I write this, so time is at a premium.</p>
<p dir="auto">One thing I'm noticing is that ES begins relocating shards as soon as the cluster is started up.  This is bad, because it results in unnecessary delays getting the cluster to the yellow, then green state.  If there are any unassigned or uninitialized shards, or the cluster status is anything other than green, shard relocation should be delayed until everything else is done, all shards are initialized and running, and the cluster state is green.</p>
<p dir="auto">An even bigger issue, and you may want to split this into two issues, is that sometimes ES leaves shards unassigned.  It just doesn't assign them.  Even if you have to start up another thread to look for unassigned shards and assign them, under no circumstances should ES ever leave a shard unassigned, period.  Doing this forces the cluster state to red, and forces the admin to manually assign those shards.  This is something ES should take care of automatically.  So...NEVER leave a shard in the unassigned state.</p>
<p dir="auto">Other than these two bugs in how ES recovers from a downed node or a complete cluster restart, ES has been fabulous for us.  Certainly a night-and-day improvement over Riak.  Keep up the awesome work!</p>
<p dir="auto">Oh...we're running the latest release, downloaded just yesterday, elasticsearch-1.4.0-1.noarch, RPM version, under Amazon Linux (RHEL), x86-64 architecture, on java version 1.7.0_71 (OpenJDK).</p>