| 05:11:52 | | DogsRNice quits [Read error: Connection reset by peer] |
| 09:10:39 | | n9nes quits [Quit: ZNC 1.8.2 - https://znc.in] |
| 09:14:16 | | n9nes joins |
| 10:06:42 | | Terbium quits [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] |
| 10:07:08 | | Terbium joins |
| 10:57:40 | | kiska quits [Read error: Connection reset by peer] |
| 10:58:56 | | kiska8 (kiska) joins |
| 10:59:13 | | mutantmonkey quits [Ping timeout: 258 seconds] |
| 10:59:13 | | HackMii quits [Ping timeout: 258 seconds] |
| 10:59:36 | | mutantmonkey (mutantmonkey) joins |
| 10:59:36 | | Zerote quits [Ping timeout: 258 seconds] |
| 10:59:46 | | HackMii (hacktheplanet) joins |
| 11:48:19 | | Matthww80 joins |
| 11:48:54 | | Matthww8 quits [Ping timeout: 250 seconds] |
| 11:48:54 | | Matthww80 is now known as Matthww8 |
| 18:16:08 | | DogsRNice (Webuser299) joins |
| 19:33:33 | | hyper212 (hyper212) joins |
| 19:59:51 | <hyper212> | No idea if this is the right channel, but I had some questions about how warrior's backend works because I'm trying to implement a similar piece of software. In particular, I was wondering how jobs were dispatched in a way that prevents one person from taking all of them. |
| 20:02:05 | <hyper212> | I was considering ways it could be implemented, but none of them seemed both efficient and foolproof. Allowing anyone to "lock" a job presents a lot of issues, and if there are no locks then that could cause jobs to run more than once. |
| 20:06:55 | <@Kaz> | so hyper212, in short - we have two handles for this kinda thing |
| 20:07:04 | <@Kaz> | 'total claims per minute' for each project |
| 20:07:10 | <@Kaz> | and also a 'total claims per nick' |
| 20:07:43 | <@Kaz> | if, on a project only the 'total claims per minute' limit was set, there's nothing stopping anyone from claiming all the jobs (given a sufficiently high concurrency) |
| 20:08:57 | <@Kaz> | with regards to locks, we consider a job 'taken' when someone claims it, but it can be manually requeued, or automatically requeued if it's not marked as completed within a given timeframe |
| 20:09:28 | <hyper212> | that makes sense |
| 20:10:12 | <hyper212> | thank you for the explanation! |
| 20:10:13 | <@Kaz> | https://tracker.archiveteam.org/reddit/ seems to be a good example of this - have a look at the completed items feed, anything that's got a strikethrough is considered a duplicate item (i.e has been returned more than once) |
| 20:10:45 | <hyper212> | oh wow, my nick went by there in strikethrough |
| 20:11:06 | <hyper212> | I never noticed that before I guess |
| 21:22:31 | | hyper212 quits [Ping timeout: 258 seconds] |