This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-04
Channels
- # aleph (2)
- # beginners (80)
- # boot (18)
- # cider (6)
- # cljs-dev (14)
- # cljsrn (5)
- # clojure (114)
- # clojure-android (5)
- # clojure-dev (8)
- # clojure-greece (6)
- # clojure-italy (9)
- # clojure-russia (108)
- # clojure-uk (82)
- # clojurescript (158)
- # css (1)
- # cursive (21)
- # data-science (1)
- # datomic (66)
- # emacs (9)
- # ethereum (3)
- # fulcro (26)
- # graphql (7)
- # hoplon (25)
- # juxt (2)
- # keechma (34)
- # lein-figwheel (4)
- # leiningen (2)
- # off-topic (4)
- # om (5)
- # onyx (14)
- # parinfer (2)
- # pedestal (17)
- # planck (3)
- # portkey (14)
- # re-frame (23)
- # reagent (12)
- # ring (8)
- # rum (1)
- # shadow-cljs (506)
- # spacemacs (2)
- # vim (11)
- # yada (6)
@lucasbradstreet i was using an out of date aeron. using this: [io.aeron/aeron-all "1.4.1"] instead of this: [uk.co.real-logic/aeron-all "0.9.4"] fixed my problem (the group had moved)
@lucasbradstreet perhaps the onyx documentation should be updated as appropriate? the code snippet in http://www.onyxplatform.org/docs/user-guide/0.11.x/#_messaging_implementations refers to the old group. i think it should be: (:import [io.aeron Aeron$Context] [io.aeron.driver MediaDriver MediaDriver$Context ThreadingMode]) not: (:import [uk.co.real_logic.aeron Aeron$Context] [uk.co.real_logic.aeron.driver MediaDriver MediaDriver$Context ThreadingMode])
@ben.mumford I’ll put a fix in — thanks for the report!
Fixed via https://github.com/onyx-platform/onyx/commit/5190d0a6b688ac4cbfd14c0bf4cce118a8adf6b6.
@michaeldrogalis drat i could have got myself down as an onyx contributer (never mind it is just documentation). keep up the good work
@ben.mumford Hah, next time. 🙂 Thanks.
We should just refer to the version in the onyx code. I might update that.
How do people generally solve the problem of a late event arriving after the other data the window it would fall into has been evicted? I assume those events evicted events are retrievable, is it up to the user to provide a way to pull them back into onyx in order to re-process the window?
@drewverlee this problem is primarily solved via watermark triggers, and buffering up the event / state updates with something like the incremental state store.
The idea is that you track the watermarks for your stream, and once you’re sure you have all of the data, you materialize the state updates into an aggregate and trigger it via the watermark trigger
are you using kafka? Our automatic watermark tracking is half finished, but I have it in my todo to finish it off over the next few days.
@lucasbradstreet thanks! I was asking more for academic reasons 🙂
OK sure, well the support is coming 🙂
Basically the idea is you buffer things up in a way that doesn’t require a lot of extra serialization, and flush when you’re sure you have all of the data