proletarian

A durable job queuing and worker system for Clojure backed by PostgreSQL: https://github.com/msolli/proletarian
Raimon Grau 2021-04-13T13:10:35.021400Z

Hello everyone, I'm new to clojure and saw the announcement, nice project! couple of things wrt proletarian: • the link to brian goetz article in the readme is 💀 , web archive has it though: https://web.archive.org/web/20201111190527/https://www.ibm.com/developerworks/library/j-jtp05236/index.html 🙂 • Coming from other languages/frameworks, the worker queue model for those short but async jobs makes total sense, but in the application I'm working on, I see sometimes future used to that effect. I get futures are not serialized and the restart logic would have to be implemented in the future itself, but still... is it true that given the concurrency primitives clojure provides, some usecases are solved by the language features? I still prefer the persistent queue model, but I'm trying to wrap my head around the new environment. (sorry if it's too generic of a question but felt like a good opportunity to pick clojurists brains) 😛

msolli 2021-04-13T18:10:39.026900Z

Hi @raimonster! Thanks for the heads up about that dead link - I’ve updated the readme with the web archive link you provided. I can also recommend chapter 7 from Brian Goetz’ Java Concurrency in Practice (2006) on this topic. You’re right, future can be, and often are, used for async work. Clojure makes this very easy to do in a safe manner. I’ve only recently converted must futures in my work codebase to Proletarian jobs. The reason is, like you’re alluding to, that the jobs are serialized to durable storage and can be retried (restarted).

msolli 2021-04-13T18:13:58.028900Z

Indeed, the inspiration for Proletarian comes from projects such as Delayed Job and Sidekiq in the Ruby world.

Raimon Grau 2021-04-13T18:17:30.030700Z

yep, I did a bunch of sidekiq/resque in the past, that's why this model makes so much sense to me to the point I feel I'm biased 😛

msolli 2021-04-13T18:42:55.034Z

There’s a nice property that Proletarian has over those projects, though, and it’s that the job can be written to the queue in the same transaction as whatever caused the job to be queued in the first place. For example, an order receipt email can be queued in the same transaction in which the order is being written.

msolli 2021-04-13T18:43:56.035100Z

Your business requirements must dictate if this extra machinery is necessary, though. Maybe a future here and there is good enough. It really depends on the use case and what guarantees you want to have.

msolli 2021-04-13T18:46:19.037300Z

Proletarian tries really hard to make sure your job is processed at least one. If the computer dies, or an external call fails (and is not catched), or any other failure happens while the job is being processed, it will get processed again, possibly by another machine, or by another thread on the same machine.