Clojurians Log v2
missionary
Hi guys! I have a main missionary task and I would like to used it in an http handler. Should I use an async ring handler or I just do something like this:
(defn http-handler [ring-req]
{:status 200 :body (m/? (main-task)})
Both choices may be correct. If you choose blocking m/? then make sure it matches the requirements of your http server
if your server supports async then callbacks are probably a better default
By requirements, you mean the number of thread, etc...?
yes, basically 1 request = 1 thread
Some terminology questions regarding terms used in the docs, since I've had trouble finding clear definitions: • What is an upstream task/flow? A downstream task/flow? • What is a child task? Is that same as a downstream task? • What is cancelation? Termination? How are they different? • What causes a task / flow / subscription to be canceled? Terminated? (Okay, this isn't a terminology question...) • What is an evaluation context? A parent evaluation context? A child evaluation context?
Good feedback, thanks. Upstream/downstream is about dataflow - an upstream process sends data to a downstream process. Parent/child is about supervision - a parent process is responsible for the lifecycle of its child processes. In current design (i.e. after the dag supervision update) the dataflow graph is always the same as the supervision graph, the child is upstream and the parent is downstream. Termination is a message sent from child to parent, i.e. in the direction of dataflow. It means the stream of data is exhausted, it can happen spontaneously (e.g. EOF) or after a crash. Cancellation is a message sent from parent to child, i.e. in the opposite direction of dataflow. It means the parent wants to shutdown the child for whatever reason, depending on the operator. The child, if still alive, must react with a crash (and eventually a termination). Evaluation context : https://gorgeous-sorbet-a5a2bf.netlify.app/synchronizers
fantastic explanation. I think it would be worth including these terms at the top of the missionary.core cljdoc (if that's possible?) since they are referenced so frequently there
A glossary is actually a great use case for a namespace level doc string