We're hitting thread scheduling issues. :/
Where (unix-time) is idential between two partitions of part-time-fast, streams/rate would divide by zero. This patch ignores the actual times in favor of just using the interval directly. This is not as accurate in cases where GC pauses interfere with thread scheduling, but I suspect in those cases part-time-fast's internal timing could *also* be inconsistent. LMAO if you care about time in Java, I guess. :-/ The right thing to do is just fix part-time, and use that.
This means part-time-fast will no longer leak threads when streams expire.
You can set up a websocket server with (ws-server) or (ws-server :host x :port 5556) The server answers websocket connections to /pubsub/<topic>. Any query can be applied as a filter: /pubsub/topic/query=true /pubsub/topic/query=(service =~ "%cat" and metric < 5.4) (query must be url-encoded, obviously) The resulting websocket will receive a stream of UTF8 frames, each containing a JSON representation of an event from that topic which matched the query. Initial testing shows excellent latency (no perceivable lag) but appears to drop events in volume. Need to investigate queue depths. Be aware that the correctness and safety of the query system are not guaranteed; just like the protobufs server, assume this system runs *arbitrary* code from the network.
core/update-index inserts events into the index for a core, also submitting them to the pubsub channel "index". config/update-index replaces streams/update-index; it is bound to the config's core. It still takes an index argument for compatibility, but presently ignores it and uses the core's instead. streams/update-index is still present, but no longer used in config. Expired events will also arrive on the index channel.