-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix #51 Expose PoolConfig, rework PoolBuilder with factory #55
Conversation
Codecov Report
@@ Coverage Diff @@
## master #55 +/- ##
============================================
- Coverage 84.68% 83.66% -1.02%
- Complexity 113 124 +11
============================================
Files 11 12 +1
Lines 457 502 +45
Branches 67 67
============================================
+ Hits 387 420 +33
- Misses 44 55 +11
- Partials 26 27 +1
Continue to review full report at Codecov.
|
@nebhale can you have a look as well? good preview of the capacity for extending the builder with a custom configuration type is displayed in the test: https://github.com/reactor/reactor-pool/pull/55/files#diff-69a164d236f7941f6d8810aa3ebc0498R112 |
This commit heavily reworks how the PoolBuilder is producing a PoolConfig (internally) and then a concrete Pool instance. The goal is to open the builder for cases where implementations would be provided by external projects (eg. a netty event-loop aware implementation for a project that pools netty connections). One can pass a factory Function to the builder to create such a custom pool, possibly also switching the builder to a custom type of configuration beforehand. As a result, the DefaultPoolConfig has now been extracted as PoolConfig and made public. As a shorthand for the `build(Function)` that produces reactor-pool vanilla implementations, we now expose `lifo()` and `fifo()`, which are now the two out-of-the-box provided flavors.
e04eda5
to
e525c3f
Compare
@violetagg @smaldini we could change the |
PoolConfig is now an interface, with a DefaultPoolConfig implementation that external pools can extend. acquisitionScheduler denotes a thread-determinism, but not all pool implementations are required to have such determinism. If they do, and the scheduler is set (to something other than immediate), then they MUST use this Scheduler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation looks good 👍
Although I'm lacking some background of the change and would suggest to verify the change with the ones who requested it (reactor-netty?)
This commit heavily reworks how the PoolBuilder is producing a PoolConfig
(internally) and then a concrete Pool instance.
The goal is to open the builder for cases where implementations would be
provided by external projects (eg. a netty event-loop aware implementation
for a project that pools netty connections).
One can pass a factory Function to the builder to create such a custom
pool, possibly also switching the builder to a custom type of configuration
beforehand. As a result, the DefaultPoolConfig has now been extracted as
PoolConfig and made public.
As a shorthand for the
build(Function)
that produces reactor-pool vanillaimplementations, we now expose
lifo()
andfifo()
, which are now the two out-of-the-box provided flavors.