Support async

[rustworthy]

As per issue

Concerns:

• Cannot use serde_json::to_writer when in async fn issue of the AsyncFaktoryCommand, so serializing into a vector and only then async writing to the buffered stream. I've read through this discussion, looks like there is simply no much interest in this feature.

Performance: In release mode, loadtest from main and loadtest from current branch are showing similar results (10-11k jobs per second on Intel Core i5-10210U, os: Garuda Linux with 6.7.0-zen3-1-zen) [I should probably get a new machine], with async version being 5-10% less performant, which should be attributed to the async runtime overhead. There is no chance the async capabilities will compensate for this overhead in the loadtest, since the job handler in this binary will not do any IO intensive tasks, where async bindings will shine (sidenote: the business logic of a job handler has never been of any particular interest in the crate's load tests, it is rather the general throughput which is being measured in loadtest).

TODO:

• [x] bid and jid deserve new-types
• [x] leave async only;
• [x] tls crate (used tokio_rustls)
• [x] tls test (already in main)
• [x] rest of Ent Faktory features (already in main)
• [x] Producer -> Client, Consumer -> Worker as per thread
• [x] address #26 (make args public)

---

This change is 

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 58.27273% with 459 lines in your changes are missing coverage. Please review.

Project coverage is 66.2%. Comparing base (ff2a27b) to head (cf3fb4e).

Additional details and impacted files

Files	Coverage Δ
src/proto/client/options.rs	100.0% <100.0%> (ø)
src/worker/builder.rs	100.0% <100.0%> (ø)
src/error.rs	42.3% <0.0%> (-1.7%)	:arrow_down:
src/proto/single/mod.rs	94.1% <94.4%> (+0.1%)	:arrow_up:
src/proto/batch/mod.rs	91.6% <62.5%> (+19.0%)	:arrow_up:
src/proto/mod.rs	50.0% <50.0%> (-20.4%)	:arrow_down:
src/worker/state.rs	93.1% <93.1%> (ø)
src/proto/single/cmd.rs	94.9% <91.0%> (-1.9%)	:arrow_down:
src/proto/single/ent/progress.rs	0.0% <0.0%> (ø)
src/proto/single/resp.rs	87.5% <90.9%> (+2.7%)	:arrow_up:
... and 14 more

... and 2 files with indirect coverage changes

[jonhoo]

Thanks for taking this on! I actually think we should go one step further and fully get rid of the sync version. I don't think there's all that much value in keeping both at the same time, and it adds significant maintenance complexity burden to the crate.

[rustworthy]

Thanks for taking this on! I actually think we should go one step further and fully get rid of the sync version. I don't think there's all that much value in keeping both at the same time, and it adds significant maintenance complexity burden to the crate.

My pleasure! I structured it this way so that to easily put it behind an async feature flag, but yes - this would mean maintenance overhead which I though one could ease a little bit with the mirrored project structure in the src/async. I will then "merge" the async version with the original one, switching to async completely.

[jonhoo]

Yeah, I see the temptation, but honestly, I think it'll be both easier, and easier to review, to just swap the whole thing over in one go :+1:

[justindthomas]

Thank you for working on this, @rustworthy! I'm currently struggling to use this library efficiently to process tasks for an async Rocket application and this improvement will be a big help.

[jonhoo]

I'm quite swamped at the moment, so will take me some time to get to this unfortunately. Apologies in advance!

[rustworthy]

I'm quite swamped at the moment, so will take me some time to get to this unfortunately. Apologies in advance!

No worries!

[jonhoo]

I'm probably going to review this on Reviewable since GitHub's interface is really bad once reviews are large, multi-staged, etc.

[rustworthy]

I'm probably going to review this on Reviewable since GitHub's interface is really bad once reviews are large, multi-staged, etc.

Ok, then I am probably going to read through their docs, but I can already tell that having stylesheets injectable is super clever

[ttdonovan]

Amazing work @rustworthy thank you for this contribution! @jonhoo what left is needed to get this merged and faktory-rs crate versions updated - starting a runtime for each worker when async is needed has been a burden lately. Let me know if there is anything I can to help move this along.

[rustworthy]

Amazing work @rustworthy thank you for this contribution! @jonhoo what left is needed to get this merged and faktory-rs crate versions updated - starting a runtime for each worker when async is needed has been a burden lately. Let me know if there is anything I can to help move this along.

The pleasure is all mine! This PR is currently being reviewed and there should be no rush, since this is going to be a breaking release. There are also a few extra PRs (signal handling and Server Info) that we will want to merge before the publication to batch breaking changes.

[jonhoo]

@ttdonovan This is mostly bottlenecked on me having review time I think. It's a pervasive change, and requires thorough review, which doesn't mix well with limited spare time. My hope is that once we land this, @rustworthy will also be in a much better position as a co-maintainer (having by then touched most of the code!), which will also help the project going forward :)

[jonhoo]

And it's in! :tada: Now for all the follow-up PRs :sweat_smile:

[jonhoo]

@rustworthy Which of the PRs you have open do you think I should review next?

[rustworthy]

@rustworthy Which of the PRs you have open do you think I should review next?

Both #57 and #59 are now ready for review