iamduo

4 ms·

1.
Workq 0.2.0 (Job server in Go)(github.com)
1 points by iamduo 10y ago|0 comments
2.
by iamduo 10y ago
Is there a reason why there aren't 2 types of jobs? One for each stage? You mentioned the first stage there is some work performed, then it sounds like you need to pass on the work again to another worker for the second stage.
3.
by iamduo 10y ago
Workq is similar to beanstalkd and was modeled after many of its concepts especially TTR and reserve ( https://github.com/iamduo/workq#credits ). The one feature which may not be obvious yet is the ability for workers to
4.
by iamduo 10y ago
It is possible, but explicitly through workers. You can have a worker block on the "result" command (it allows for a wait-timeout) and wait for the successfully completion of Job X and enqueue Job Y. There is no way to define th
5.
by iamduo 10y ago
Heh yes... http://ledisdb.com
6.
by iamduo 10y ago
RabbitMQ can do much of what Workq can do from a purely messaging standpoint since input and output looks about the same. Workq is built on the higher level concept of a job so the feature set is refined around what a job is. In Workq, a jo
7.
by iamduo 10y ago
There is no individual progress streaming at the moment. It was on the drawing board, but was slashed for simplicity and time. Just curious, what would you use it for in your case?
8.
by iamduo 10y ago
This is the same reason why Workq is intended to be standalone. It takes so much expertise and time to implement this in a distributed nature. I spent 80% of time on Workq just writing tests for it and there is still so much to account for
9.
by iamduo 10y ago
I can definitely agree on the HTTP tooling! As for the HTTP2 portion, the server details would be abstracted out especially with HTTP2 support in Go 1.6. At the time I looked, HTTP2 clients for various languages were still popping up and st
10.
by iamduo 10y ago
Can you clarify the missing robustness features?
11.
by iamduo 10y ago
A big yes to this! Signal handling will be covered in a future update. This is critical to Workq, being that it is intended to run as a standalone. A zero downtime deployment is required. There will be a more in-depth roadmap in the repo so
12.
by iamduo 10y ago
A job in Workq doesn't directly target a system command or anything. The short answer is a job could be thought of as a function call. The name of the job is the function, and the job's payload is its parameters. This allows a wor
13.
by iamduo 10y ago
The text interface primarily has simplicity on its side. The goal was to implement a set of commands with a small footprint. HTTP would have provided "too much" for me to worry about in terms of designing the commands. However, HT
14.
by iamduo 10y ago
Thanks. Simplicity was the main goal and I took many passes eliminating cruft. The initial plans for persistence is to disk, in the form of a Command Log. Similar to VoltDB's Command Log or Redis' AOF. A simple approach to durabil
15.
by iamduo 10y ago
That is correct, beanstalkd was an inspiration for this project. I've even credited it here: https://github.com/iamduo/workq#credits . Could you describe what the use case of the move-tube command was? More specifi
16.
Show HN: Workq – Job Server in Go(github.com)
185 points by iamduo 10y ago|59 comments