* origin/topic/timw/storage-timeout-testing:
Fix handling of timeout conditions from storage backends
Reformat plugin.storage btest to be more consistent with other storage tests
The ts parameter was only added to Call() for the Broker::auto_publish()
functionality and propagating the network timestamp. By now, the auto-publish
functionality is deprecated, so it'd be good to cleanup that signature. There
won't be any need for no_remote in the future either.
Allow users to just use Call() instead.
Avoid proliferation of various members on EventMgr by storing the
pointer of the current event instead.
This subtly changes the behavior of some builtin functions as they would
have returned the prior event's data when executed outside of event
draining (e.g. C++ level hook invocations), but I think that's actually
for the better.
Calling collect_metrics() from a script would not invoke metric
callbacks, resulting in most of the process metrics to be zero
when a Zeek process isn't scraped via Prometheus.
Fixes#4309
The busy polling wasn't clever and usually resulted in delays. For now,
switch to mutex/condition variable and log an error if the timeouts are
immense.
Due to prefix matching, worker-1's node_topic() also matched worker-10,
worker-11, etc. Suffix the node topic with a `.`. The original implementation
came from NATS, where subjects are separated by `.`.
Adapt nodeid_topic() for consistency.
WebSocket clients that connected with the wrong URL do not have
a backend attached. If a dispatcher is terminated while these
clients are still connected, a null deref would happen.
This was found while running all cluster/websocket tests in a loop
for a long time, tickling a segfault during the bad-url test.
These test were very sensible to the speed at which ZeroMQ distributes
subscriptions in the cluster and showed to be unreliably when testing with
zeek/btest#113.
The main fix here is to have individual WebSocket clients subscribe to unique
topics, e.g /test/client-0 and /test/client-1, instead of just a shared topic.
This ensures the WebSocket handshake completes only when they observed their
own subscriptions and not prematurely when observing the shared topic.
This seems mainly relevant for tests: In the real world one shouldn't
rely on subscription visibility - you miss messages if you're too late
to the party.
When two workers connect to zeek.cluster.worker, the central ZeroMQ
proxy would not propagate unsubscription information to other nodes
once they both left. Set ZMQ_XPUB_VERBOSER on the proxies XPUB socket
for visibility.
* origin/topic/timw/storage-framework-followup:
Redis: Handle other errors from requests, fix KEY_EXISTS for put operations
SQLite: handle existing keys when overwrite=F correctly
Remove unnecessary type aliases from storage btests
Avoid thread-leak in scripts.base.frameworks.file-analysis.bifs.enable-disable btest
Fix data-race with calling DBG_LOG from a separate thread
Fix data-race with ReturnCode objects in Sqlite::DoExpire
Fix data race with calling run_state::network_time from a separate thread
Add NEWS entry for Storage, reduce CHANGES spam
Fix Coverity findings in the SQLite backend
Remove inclusion of non-existent expected-lite path during dynamic plugin builds
Squash code from OperationResultCallback into ResultCallback
Add hiredis to generate-docs workflow to enable Redis backend