(def ch (async/chan 10))
(go (async/>! ch data))

you have 1024 pending puts per unbuffered channel, no matter the number of go blocks & co, if buffered add the buffer size to that, otherwise if sliding/dropping etc, it doesn't really matter. It's quite easy to test

(put! ch x) and (go (async/>! ch x)) are equivalent with regards to pending tasks number

if you go over the pending put queue size it will throw fyi

@mpenet Thanks! Is there any way to get a count of how many of the 1024 we've used up (and possibly what those pending messages are)? I'm debugging a production server, I created a /health endpoint which basically does a sub, and a (go (async/>! ch :test-message)) and after about 30-45min this stops working.

@mpenet got it, figured out how to print the put queue size: (.size (.puts ch)). Thanks for your help again. And wish me luck debugging, this is someone else's code. Yikes.

@naartjie godspeed

LOL

1) that go block is better written as (put! ch :test-message) 2) make sure all the topics have consumers, and check that the messages have the topics you think they do

(that is, all the topics generated by the pub that you sub to)

Right, if you ever hit the limit of 1024 pending puts on a channel, chances are really high that you have a bug in your code. The limit is artificial and is designed to provide quicker feedback in the case of an unbounded queue.

Couldnt agree more

@noisesmith I guess (hope) the go example is a slimmed down example

in my experience, core.async code that uses go blocks for a single channel put is common - but of course if they are doing more than that it won’t translate to put! and the suggestion is moot