Still finding it to not be foolproof enough to enable generally for all
nodes in a cluster. Specific/advanced use-cases may still consider
enabling, possibly just for specific nodes.
* origin/topic/johanna/weird-options:
Update test baselines (weird options)
Weird settings: make constants into options.
Permit weird sampling rate of 0.
* origin/topic/jsiwek/bit-1967:
Fix a routing loop in control framework
Add Broker::forward() function
Enable implicit Broker message forwarding by default
Remove Cluster::broadcast_topic
Remove Intel Broker topics, re-use existing Cluster topics
Remove "relay" family of Broker functions
This enables explicit forwarding of events matching a given topic
prefix. Even if a receiving node has an event handler, it will not
be raised if the event was sent along a topic that matches a previous
call to Broker::forward().
Namely these are now removed:
- Broker::relay
- Broker::publish_and_relay
- Cluster::relay_rr
- Cluster::relay_hrw
The idea being that Broker may eventually implement the necessary
routing (plus load balancing) functionality. For now, code that used
these should "manually" handle and re-publish events as needed.
The loop over Reducers in SumStats::observe performs a key normalization
and inadvertently modifies the key used for subsequent iterations.
Reported by Jim Mellander.
Now defaults to a max of 4 threads typically indepedent of core
count (previously could go up to a hard cap of 8). Also now allow
controlling this setting via BRO_BROKER_MAX_THREADS environment
variable.
BIT-1958 #merged
* origin/topic/johanna/config-cluster:
Add vector to read_config_cluster test.
Fix special-case-bug for vectors in UnaryExpr.
Config: another cluster test-case, this time reading in a file.
Add sending of values to nodes that dropped out.
Continue work on config framework clusterization.
Teach Option::set to unwrap Broker::Data values
Start clusterizing configuration framework.
The former replaces the pcap vs. live versions of the same tuning
option. If a user does not change these, Bro makes some internal
decisions that may help avoid performance problems on systems with high
core counts: the number of CAF threads is capped at 8 and the maximum
sleep duration for under-utilized threads is increased to 64ms (CAF's
default is 10ms).
These may be used to change the number of scheduler threads that the
underlying CAF library creates. In pcap mode, it's currently hardcoded
to the minimal 4 threads due to potentially significant overhead in CAF.
This environment variable is now set to listen only on IPv4 loopback
when running unit tests (instead of using the default INADDR_ANY).
This also moves some of the @loads out from init-bare.bro into a new
init-frameworks-and-bifs.bro in order to better support calling BIFs
(like `getenv`) from variable initializations in those particular
frameworks.
This is a fairly straightforward change. Previously, users had no
control over whether this script was loaded. By relocating it to
policy, users can now choose whether or not this is necessary
functionality without modifying core Bro scripts.
