This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-17
Channels
- # adventofcode (2)
- # beginners (153)
- # cider (14)
- # clara (9)
- # cljs-dev (8)
- # cljsjs (1)
- # cljsrn (4)
- # clojure (124)
- # clojure-dev (9)
- # clojure-france (18)
- # clojure-greece (22)
- # clojure-italy (11)
- # clojure-nlp (5)
- # clojure-russia (9)
- # clojure-spec (21)
- # clojure-uk (40)
- # clojurescript (82)
- # core-async (12)
- # cursive (3)
- # data-science (2)
- # datomic (225)
- # devcards (8)
- # docs (2)
- # duct (1)
- # emacs (18)
- # figwheel (2)
- # fulcro (117)
- # graphql (13)
- # hoplon (10)
- # jobs (7)
- # jobs-discuss (7)
- # keechma (8)
- # leiningen (4)
- # off-topic (16)
- # om (2)
- # om-next (3)
- # perun (11)
- # precept (4)
- # re-frame (24)
- # reagent (2)
- # remote-jobs (8)
- # ring (2)
- # ring-swagger (9)
- # rum (42)
- # shadow-cljs (8)
- # spacemacs (3)
- # specter (7)
- # uncomplicate (10)
- # unrepl (58)
- # yada (9)
promise chans where not part of the initial release of core-async and changing the return value of go block would not be backwards compatible
it could break stuff in some weird cases: promise-chan will always return the delivered value (or nil), a go block would deliver a single value, once.
i know i’ve seen some talk of kafka+core.async in here before so wondering if anyone has any insight. i’m looking at taking kafka messages and putting them into core.async channels for processing, but i also want to explicitly commit the message offsets. i’m wondering if i should attach a ‘callback’ to each item on the channel that commits the relevant offset and have the receiver call that after processing
the tricky thing here is that if you use proper backpressure, you’ll get problems with kafka under heavy load situations - it gets testy if you wait too long to commit offsets iirc
hmmm i’m fairly new to kafka
i assumed as long as the consumer is still heartbeating kafka shouldn’t care when you commit offsets
but that could be wrong
i think i’m just going to skip core.async for now and do the processing on the polling thread and commit after i process a batch from poll()
don’t really have an idea of performance requirements yet so no need to over engineer i guess
if you are looking for performance you probably don’t want core.async - not that core.async performs poorly, but it isn’t a performance enhancing tool. It’s for coordinating between asynchronous states. If the thing you do that optimizes performance involves synchronization concerns as part of the solution, core.async can help there though.