Fork me on GitHub
#jackdaw
<
2019-06-20
>
dharrigan07:06:16

Hi, is my assumption correct, on the client consumer (i'm just creating a process that simply consumes from a kafka topic, not streaming it to another topic), in client.log/log if I pass in a function for fuse-fn then once that function returns fails, the consumer will stop?

cddr09:06:03

Yep. If the fuse-fn is provided, as soon as it returns false, the fuse is blown.

dharrigan09:06:47

Cool. Would there be an example of usage? I'm just wondering how to do this, so that (from a separate namespace) I can update the fuse

cddr10:06:23

Maybe use a promise or something? e.g. this isn't in a separate namespace but I assume what you mean is that you want to blow the fuse independently of processing the records....

(let [p (promise)
       records (jdc/log consumer 2000 (fn [_]
                                                                 (not (realized? p)))]
   (future
      (doseq [r records]
         (process r)))

   (Thread/sleep 10000)
   (deliver p :done))
That being said, I'm not a huge fan of this part of the API. I think the intention is to allow more idiomatic clojure by providing a lazy sequence view of some consumer. However, I tried to add some tests a while back and got a bit stuck (which is why there's no examples I can point you to). I've heard people say it's not usually a good idea to mix lazyness and IO so that might be part of the problem but I'm not sure.

dharrigan10:06:18

That's very helpful 🙂

dharrigan10:06:36

I was also thinking of having a go channel, and simply return true until a false gets shoved in 🙂

dharrigan10:06:42

not sure if that would work, but I'll have a play!

dharrigan10:06:10

very helpful! 🙂

cddr10:06:15

The test-machine includes some lower-level code that polls in a separate thread so that test result data can be collected into a journal independently of the main thread which checks what has been collected once the test is considered complete. It uses manifold but a prior version used core.async so both approaches can be made to work. https://github.com/FundingCircle/jackdaw/blob/master/src/jackdaw/test/transports/kafka.clj#L91

kelveden11:06:00

@cddr Thanks for merging my PR earlier. As far as getting the code released is concerned, it's presumably a case of waiting for the next release cycle, right? I can see on clojars that the pattern seems to be that PRs automatically get deployed as snapshot releases to clojars but mine didn't because I'm not an FC employee (and hence don't have access to deploy snapshots).

cddr11:06:30

Ah yeah we should probably configure it to publish snapshots for all merged PRs. I thought it would do that but I just checked and it doesn't seem to have done it. I was going to publish a release this evening anyway. There's a few things worth getting out there (yours not least among them). But we'll have to think about ideas to make it easier for contributors to publish a jar with their changes. Might have a chat over in #clojars and see if there's any existing solutions for this type of thing.

kelveden11:06:16

:thumbsup: sounds good; thanks!

kelveden11:06:10

I think that the fact I setup my forked build to run on Circle CI confused things - that's the build that failed. If I hadn't done that and there was a hook configured from github to circle to build PRs that would do the trick?

cddr11:06:45

I'm not sure. It seems to pretty reliably fail at that step for external developers regardless of what they do. :man-shrugging:

Travis18:06:36

@cddr It appears to be working and doing what I needed

bananadance 4