<div dir="ltr">Couple questions. (Let me know if this isn't appropriate bro-dev content, but I don'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 'manager'? <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'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 'manager' for cluster store 'bro/known/certs' does not exist</div></div><div><br></div><div>Second, when during startup should Bro know that it's persistent stores exist via Cluster::stores() ? It appears bro_init may be too soon, but I'm still playing. Also, it'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"><<a href="mailto:jazoff@illinois.edu" target="_blank">jazoff@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On May 11, 2018, at 10:13 AM, Jon Siwek <<a href="mailto:jsiwek@corelight.com">jsiwek@corelight.com</a>> wrote:<br>
> <br>
> <br>
> There's no check against the local cache to first see if the key exists <br>
> 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'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'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>