This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-30
Channels
- # aws (2)
- # beginners (139)
- # boot (9)
- # cider (1)
- # clara (2)
- # cljs-dev (35)
- # cljsrn (3)
- # clojure (112)
- # clojure-dusseldorf (9)
- # clojure-greece (6)
- # clojure-italy (13)
- # clojure-russia (160)
- # clojure-seattle-old (1)
- # clojure-uk (79)
- # clojurescript (85)
- # clojutre (1)
- # community-development (11)
- # core-async (32)
- # cryogen (2)
- # cursive (5)
- # data-science (16)
- # datomic (2)
- # events (1)
- # fulcro (29)
- # funcool (1)
- # graphql (4)
- # immutant (5)
- # instaparse (20)
- # jobs (2)
- # juxt (6)
- # leiningen (11)
- # luminus (21)
- # lumo (1)
- # off-topic (7)
- # onyx (20)
- # parinfer (33)
- # pedestal (4)
- # re-frame (41)
- # reagent (34)
- # ring-swagger (14)
- # rum (5)
- # spacemacs (9)
- # specter (11)
- # sql (14)
- # test-check (3)
- # yada (20)
I've got a function that mimics the RxJS startWith
method, but wondering if there's a built in way to start a channel with a value:
(defn start-with [ch v]
(a/put! ch v)
ch)
It s quite common when you can t (or dont want to) block (ex in erlang where process mailboxes size is unbounded, so msgs producers have to be carefull not to flood their consumers mb)
@rplevy this is why I strongly recommend not using push-based subscriptions with web apps.
the protocols in play just don't support good rate limiting and flow control. A much better option I've found is to only send "most recent message" IDs to the app. These messages can then be thrown away via a sliding window. Then the webapp can make a pull-based request to the back end for a range of messages.
This then allows the client to know how far behind "current" it is, and the client also then has the option to do batching, or to throw out entire groups of messages if it gets too far behind.
With push-based protocols you're limited to drinking out of a firehose that the server hands you.
Also, push-based approaches are really hard to write in a way that they properly handle slow clients. I've seen systems where all the clients on a single back-end server are limited to the same rate. I've also seen systems that cause OOM errors on servers due to too much buffering by a slow client.
You can get rid of all those problems by simply using a pull model.
does anyone has experienced problems using core.async
with the jdbc/with-db-transaction
macro? no matter what i do i keep getting Exception in thread "async-thread-macro-18" java.lang.Error: java.sql.SQLException: No operations allowed after statement closed.
@plins with-db-transaction closes the connection at the end of the macro, and isn't aware of the fact that code is using it from another thread
so if you hand off that connection to another thread that processes async, like core.async, then that will always happen if the macro block is exited from before that core.async block has finished running
best solution: don't use core.async with jdbc, because jdbc isn't async (and therefore you're going to block your core.async threads anyways)
you can still use jdbc inside async/thread - sometimes that’s useful
other solution: initialize the with-db-transaction
block inside a core.async go block and then park on waiting for everything that depends on that transaction to have finished
and like @noisesmith said, make sure you run your actual DB commands a separate thread (probably via core.async/thread
) so you don't block the small core.async thread pool
thread lets you coordinate asynchronously with db results while doing other stuff, which isn’t as good as having an async db driver but hey that’s jdbc’s problem fundamentally
here is what happening:
i have a db-layer/dao with lots of small functions, all of them encapsulates the queries with async/thread
on top of it, theres a service/controller, which calls (should) start a transaction and call these functions
is there any reason not to scope the transaction to the thread body?
or do you mean there’s more than one?
if you aren’t doing async inside the transaction that should be fine…
(async/thread
(jdbc/with-db-transaction
....
(async/thread ;; inside a function by the way
so this is problematic(async/thread
(jdbc/with-db-transaction
....
(function-which-calls-async/thread
this is clearerif you don’t block on the result of the inner async/thread call, yes it is a potential problem
because the function can return before the thread finishes