Most would perhaps start with the classic approach of having each request
contain a :reply-to channel that the responses go into, but I think this is
a mistake.
IMO, there are two main ways of building systems with core.async 1)
request/response. 2) dataflow graphs.
I prefer the second approach which is to view services as pipeline stages.
For example you might write something like this in clojure:
(-> (read-file-list)
(map load-image)
(map resize-image)
(map save-image))
You could easily then write this sort of thing as a pipeline:
(let [file-chan (chan 1024)
image-chan (chan 1024)
resized-chan (chan 1024)]
(read-file-list file-chan)
(load-images file-chan image-chan)
(resize-images image-chan resized-chan)
(save-images resized-chan))
In addition, you can have these pipelines stages use async/pipeline-*
functions to give you very clean knobs with which to tune your system.
And finally, when it comes time to distribute processing it's fairly
trivial to replace the channels in the second example with a durable
message queue, and suddenly you can go from a system running on one machine
to one running on multiple machines (granted with different failure
characteristics, but I digress).
So try to think of your system as a pipeline and not so much as
request/response calls. Even things like HTTP servers with their stack of
middleware can be viewed as a processing pipeline, and in fact this is way
some libraries, like Pedestal, model them.
Timothy
On Wed, Jan 6, 2016 at 3:00 PM, William la Forge <laforg...@gmail.com>
wrote:
> Let each request carry the callback channel. It is then the requestor's
> option to reuse a channel for multiple requests or to open one for each
> request or some combination.
>
> For example, some requests might get a lot of responses and the requestor
> may need to close the channel before getting them all. Obviously in this
> case you would want the request to have its own dedicated channel.
>
> In general I'd start with one channel per request and then optimize as
> needed. :-)
>
> --
> 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.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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.
