Broker::subscribe() after Broker::peer() may result in losing messages,
always best to do the reverse order.
Also possibly improved chance of unstable unit test output order.
* origin/topic/jsiwek/dns-mgr-fixes:
Fix timing out DNS lookups that were already resolved
Remove an unhelpful/optimistic DNS_Mgr optimization
Fix DNS_Mgr priority_queue usage
Remove dead code from DNS_Mgr
Improve DNS_Mgr I/O loop: prevent starvation due to busy Broker
Fix a ref counnting bug in DNS_Mgr
* origin/topic/robin/gh-239:
Undo a change to btest.cfg from a recent commit
Updating submodule.
Fix zeek-wrapper
Update for renaming BroControl to ZeekControl.
Updating submodule.
GH-239: Rename bro to zeek, bro-config to zeek-config, and bro-path-dev to zeek-path-dev.
Checking a subscriber for available messages required locking a mutex,
but we should never actually need to do that in the main-loop to check
for Broker readiness since we can rely on file descriptor polling.
Note - this compiles, but you cannot run Bro anymore - it crashes
immediately with a 0-pointer access. The reason behind it is that the
required clone functionality does not work anymore.
* origin/topic/johanna/243:
Fix missing include file on Linux
Deprecations: Update NEWS, and tie up a few loose ends.
Remove support for using &&/|| with patterns.
Remove RemoteSerializer and related code/types.
Remove PersistenceSerializer.
Remove synchrnized and persistent attributes.
Now retrieves and processes all N available responses at once instead
of one-by-one-until-empty. The later may be problematic from two
points: (1) hitting the shared queue/mailbox matching logic once per
response instead of once per Process() and (2) looping until empty is
not clearly bounded -- imagining a condition where there's a thread
trying to push a large influx of responses into the mailbox while at
the same time we're trying to take from it until it's empty.
Looked like a possible race condition in how the test was structured: an
endpoint sees its peer got lost and likewise exits immediately before
having a chance to process events the peer had sent just before exiting.
Fix is to reverse which endpoint initiates the termination sequence so
we can be sure we see the required events.
This a convenience for those that are upgrading. If we didn't do
this, then deployments can silently break until the user intervenes
since BroControl now prefers to load the initially-vanilla local.zeek
instead of the formerly-customized local.bro.
This commit removed functions/events that have been deprecated in Bro
2.6. It also removes the detection code that checks if the old
communication framework is used (since all the functions that are
checked were removed).
Addresses parts of GH-243
This could happen in the case of making repeated lookup requests
for the same thing within a short period of time: cleaning up an
old request that already got resolved would mistakenly see a new,
yet-to-be-resolved request with identical host/addr and mistakenly
assume it's in need of being timed out.
