<div dir="ltr">Couple questions.   (Let me know if this isn&#39;t appropriate bro-dev content, but I don&#39;t want to cause confusion on the normal bro list.)<div><br></div><div>First, can Cluster::default_master_node be changed to default to the name of the current manager node rather than specifying the name as &#39;manager&#39;?  <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Easy to redef to the manager&#39;s name, but less easy when you use the same code base on multiple clusters with different names.</span></div><div><br></div><div><div>==== stderr.log</div><div>fatal error in /usr/local/bro/share/bro/base/frameworks/cluster/./main.bro, lines 399-400: master node &#39;manager&#39; for cluster store &#39;bro/known/certs&#39; does not exist</div></div><div><br></div><div>Second, when during startup should Bro know that it&#39;s persistent stores exist via Cluster::stores() ?  It appears bro_init may be too soon, but I&#39;m still playing.  Also, it&#39;d be nice if the persistence of built-in stores (like known/hosts, known/certs, etc) were redef-able.</div><div><br></div><div>Thanks,</div><div>-Dop</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 11, 2018 at 1:38 PM, Azoff, Justin S <span dir="ltr">&lt;<a href="mailto:jazoff@illinois.edu" target="_blank">jazoff@illinois.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt; On May 11, 2018, at 10:13 AM, Jon Siwek &lt;<a href="mailto:jsiwek@corelight.com">jsiwek@corelight.com</a>&gt; wrote:<br>
&gt; <br>
&gt; <br>
&gt; There&#39;s no check against the local cache to first see if the key exists <br>
&gt; as going down that path leads to race conditions.<br>
<br>
</span>What sort of race conditions?<br>
<br>
Right now I see a lot of events going around so it seems like there may be a bit of overhead in this area.<br>
<br>
For example, in about a minute one node in a two node cluster sent 2104 Software::register events (so likely 4k total)<br>
In that time, only 7 new entries were logged to software.log.<br>
<br>
It&#39;s always good to reduce memory usage, but I think especially for things like known hosts which are generally kept at LOCAL_HOSTS<br>
the small amount of memory used for caching already seen hosts saves more resources than would be spent sending redundant events around.<br>
Especially if those events end up queued and buffered in ram anyway.<br>
<br>
Things are a bit better off now in that we can use a short lived cache, since the cache doesn&#39;t need to be the actual data store anymore like the old known hosts set was.<br>
<br>
<br>
<br>
— <br>
<span class="HOEnZb"><font color="#888888">Justin Azoff<br>
<br>
</font></span></blockquote></div><br></div>