Fork me on GitHub
#core-async
<
2018-01-17
>
isaac12:01:21

why not go return a promise chan for go block?

schmee12:01:16

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

isaac13:01:30

Got it, I think use promise chan will not breakup usage

mpenet14:01:35

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.

nickmbailey15:01:28

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

noisesmith17:01:21

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

nickmbailey18:01:32

hmmm i’m fairly new to kafka

nickmbailey18:01:58

i assumed as long as the consumer is still heartbeating kafka shouldn’t care when you commit offsets

nickmbailey18:01:30

but that could be wrong

nickmbailey18:01:09

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()

nickmbailey18:01:50

don’t really have an idea of performance requirements yet so no need to over engineer i guess

noisesmith18:01:23

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.