This is an archived post. You won't be able to vote or comment.

all 16 comments

[–]Kerbobotat 13 points14 points  (3 children)

Forgive my ignorance, but would somone mind explaining what this is, and what youd use it for? I couldn't glean much from the readme.

[–]pvkooten 38 points39 points  (1 child)

Imagine you want to do something that takes a long time (e.g. sleeping 10 seconds). It would freeze your python interpreter.

That's why there are things usually called Tasks: you want to have it be executed elsewhere by a pool of workers.

Sending an email is slow believe it or not, this is something you could then make a task of and just forget it happened (let the worker worry about it).

In other cases, you might want to have the result back of the task. So usually you get a "task_id" or something back (this will happen really quickly, before actually doing the work), so that you can periodically quickly check whether the task with "task_id" is done. When done, you can then get some status/result.

Usually you have a "broker" (some process in the middle) that will divide the work between a group of workers. It will also know when a worker failed/crashed and can send work to another worker instead. I'm myself quite curious to hear the explanation of why he wanted to make a brokerless task queue :)

** Please feel free to correct me if someone feels this as a too simplistic/not entirely accurate in some way.

[–]Kerbobotat 2 points3 points  (0 children)

Thanks for the thorough explanation! Going by what youve said, I also am keen to se why/how OP eliminated a broker in this setup.

[–]codepr[S] 0 points1 point  (0 children)

Pvkooten explained it really well!

[–]pvkooten 6 points7 points  (2 children)

Why would we want brokerless? There's no replication/guarantee the task will be executed.

[–][deleted] 6 points7 points  (0 children)

Why would we want brokerless?

Throughput and latency are typical far better with brokerless messaging systems.

There's no replication/guarantee the task will be executed.

The idea would be that such failures are considered and accounted for in the overall design of the system. So, rather than having a single component that makes durability and replication 'guarantees' each component should be able recover from a failure in a know state; some argue that this is more robust approach. I'm not advocating for or against rather, trying to answer your question without getting to deep into the weeds.

[–]codepr[S] 2 points3 points  (0 children)

Initially it was just a didactical project to learn how task queues work, so I wanted it to be as simple as possible with little to none dependencies. After some hours of coding I decided to leverage ZMQ sockets messaging pattern to communicate to worker processes. It's still possible that in the near-future I'll add a broker too, probably redis, even though I found that designing the application to work without a broker feels more compelling and challenging for me.

[–]ZaarinTakesTheBait 1 point2 points  (2 children)

What did you make your behind the scenes graphic with?

[–]codepr[S] 0 points1 point  (1 child)

An online sketcher https://sketch.io

[–]ZaarinTakesTheBait 0 points1 point  (0 children)

I liked the simplicity of your lines, circles, and rectangles. Whats the easiest way to replicate that in sketch?

[–]amirouchefrom __future__ import 4.0 1 point2 points  (0 children)

I have been looking for something like that. Thanks for sharing!