Hi Nahuel, I think it's worth stepping back from discussing solutions and have a look at the problem. If I'm reading things right you need the following:
1. Producer produces values one at a time - should not step until last value has been handled correctly elsewhere. 2. Middleman needs to consume one value and (potentially) retry an external service until it can verify correct handling. 3. Producer should not interpret the consumption of a value as a signal to proceed. You also seem to want the following: a. Use core.async b. Make the solution "elegant" That's all fine, but it seems like a bit of a golden hammer. Your problem is precisely not the kind of problem core.async channels are designed to solve. Channels are there to provide decoupling of producer and consumer, whereas you, in fact, need the kind of coupling provide by function calls. Channels are for when you don't want to know how or when your product is handled. You're finished, you throw the product on a channel, and you move on to making your next product. All you ever find out is if/that your product has been picked off the channel. Function calls are for when you do need to know what happened to your product, and when it has all happened, because you can't move on until the last thing has been done. Just call the middleman in synchronous code in your producer, with one value, and look at its return value to tell you what to do next. You get your blocking semantics (1-3) and you also get information about success or failure. Using channels, consumption is the only information the producer hears back. To tell the producer you've completed your mission as middleman, you'll need another channel. If you really want to use core.async: (>! c v) ; blocks until consumed (respond-to (<! ackchan)) ; blocks until handled ...do expensive stuff but this is just an expensive function call. Regards, Fergal Byrne On Thu, Oct 9, 2014 at 11:16 AM, Eduard Bondarenko <edb...@gmail.com> wrote: > I think the point is to not generate values by producer if external > service is not available > "The producer only unparks when the value is effectively consumed by > the external service. That's my objective." > > "external ready" channel here serves as a latch that stops producer > generating value. > > On Thu, Oct 9, 2014 at 6:39 AM, Fluid Dynamics <a2093...@trbvm.com> wrote: > > On Monday, October 6, 2014 9:36:59 AM UTC-4, edbond wrote: > >> > >> Add one more chan, "external ready". > >> Put :ok there to let producer generate new value. > >> > >> producer: > >> - read from "external ready" > >> - generate value > >> - put into "outgoing" chan > >> > >> client: > >> - contact external server, put in "external ready" if ok > >> - read from "outgoing" chan > >> - send to external > >> > >> Handle exceptions and loop where you need. > > > > > > If you're not reading from "outgoing" until the external server is known > to > > be ready, you don't need the "external ready" channel. Backpressure on > the > > "outgoing" channel will suffice to keep the producer from overrunning the > > consumer in this case. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to a topic in the > > Google Groups "Clojure" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/clojure/QbiwXYDw6oA/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Fergal Byrne, Brenter IT http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne Founder of Clortex: HTM in Clojure - https://github.com/nupic-community/clortex Author, Real Machine Intelligence with Clortex and NuPIC Read for free or buy the book at https://leanpub.com/realsmartmachines Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/ and at LambdaJam Chicago, July 2014: http://www.lambdajam.com e:fergalbyrnedub...@gmail.com t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie http://www.adnet.ie -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
