For discussion: add in-process async
mode to Puma plugin
#115
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First, let me apologize for dropping what is essentially a spike; I figured it was simplest to share some real code.
I wanted to see how difficult it would be to add an "async" mode to the puma plugin that would run the workers/dispatchers in the same process rather than forking. Not difficult at all! 馃馃徎
Working on this did expose a few questions that I had about what an ideal implementation would be:
Configuration
I added a new "mode" to the Puma plugin, and also overloaded the worker configuration to make "processes: 0" mean something new. I think they're somewhat redundant.
processes: 0
is not great (maybe someone wants to disable a worker but retain the configuration; this would make that more difficult). I went with0
because I didn't want to mix integers and strings (e.g.processes: async
) and...In this implementation, it's not possible to mix both async and forking, and I think that could be nice (or maybe too complicated!). I could imagine async as general mode of SolidQueue rather than specific to the Puma plugin to allow mixing-and-matching async and forked workers through the CLI too.
Supervision
I made a new object called
AsyncSupervisor
which is overloading the concept ofSupervisor
a bit. It also made me think, if async and forked workers could be operated simultaneously there would need to be an object (a "Director"?) that managed both anAsyncSupervisor
andSupervisor
... and that was the point where I figured I should just share where I'm at 馃槉Slimming down workers
Lastly, I think this naive spike still leaves the
Worker
objects with some behavior that maybe isn't necessary (process registration, each having their own heartbeat) or possibly bad (e.g. setting the procline). It might be as simple as adding a few moreif supervised?
checks because I didn't see anything that strongly-strongly implied that Workers must run in a subprocess.Lastly, I wanted to try this just to dig into SolidQueue, so please feel free to disregard/dispose of it if you already have completely different ideas for how to implement this functionality. I'm excited regardless 馃帀