PoolConfig (Reactor Pool 0.1.2.RELEASE)

All Known Implementing Classes:

DefaultPoolConfig
```
public interface PoolConfig<POOLABLE>
```
A representation of the common configuration options of a Pool. For a default implementation that is open for extension, see DefaultPoolConfig.

Author:

Simon Baslé

Method Summary

All Methods Instance Methods Abstract Methods
Modifier and Type	Method and Description
`Scheduler`	`acquisitionScheduler()` When set, `Pool` implementation MAY decide to use the `Scheduler` to publish resources in a more deterministic way: the publishing thread would then always be the same, independently of which thread called `Pool.acquire()` or `PooledRef.release()` or on which thread the `allocator()` produced new resources.
`AllocationStrategy`	`allocationStrategy()` `AllocationStrategy` defines a strategy / limit for the number of pooled object to allocate.
`Mono<POOLABLE>`	`allocator()` The asynchronous factory that produces new resources, represented as a `Mono`.
`java.time.Clock`	`clock()` The `Clock` to use to timestamp pool lifecycle events like allocation and eviction, which can influence eg.
`java.util.function.Function<POOLABLE,? extends Publisher<Void>>`	`destroyHandler()` Defines a mechanism of resource destruction, cleaning up state and OS resources it could maintain (eg.
`java.util.function.BiPredicate<POOLABLE,PooledRefMetadata>`	`evictionPredicate()` A `BiPredicate` that checks if a resource should be destroyed (`true`) or is still in a valid state for recycling.
`int`	`maxPending()` The maximum number of pending borrowers to enqueue before failing fast.
`PoolMetricsRecorder`	`metricsRecorder()` The `PoolMetricsRecorder` to use to collect instrumentation data of the `Pool` implementations.
`java.util.function.Function<POOLABLE,? extends Publisher<Void>>`	`releaseHandler()` When a resource is `released`, defines a mechanism of resetting any lingering state of the resource in order for it to become usable again.

- Method Detail
  - allocator
```
Mono<POOLABLE> allocator()
```
    The asynchronous factory that produces new resources, represented as a Mono.
  - allocationStrategy
```
AllocationStrategy allocationStrategy()
```
    AllocationStrategy defines a strategy / limit for the number of pooled object to allocate.
  - maxPending
```
int maxPending()
```
    The maximum number of pending borrowers to enqueue before failing fast. 0 will immediately fail any acquire when no idle resource is available and the pool cannot grow. Use a negative number to deactivate.
  - releaseHandler
```
java.util.function.Function<POOLABLE,? extends Publisher<Void>> releaseHandler()
```
    When a resource is released, defines a mechanism of resetting any lingering state of the resource in order for it to become usable again. The evictionPredicate() is applied AFTER this reset.
    For example, a buffer could have a readerIndex and writerIndex that need to be flipped back to zero.
  - destroyHandler
```
java.util.function.Function<POOLABLE,? extends Publisher<Void>> destroyHandler()
```
    Defines a mechanism of resource destruction, cleaning up state and OS resources it could maintain (eg. off-heap objects, file handles, socket connections, etc...).
    For example, a database connection could need to cleanly sever the connection link by sending a message to the database.
  - evictionPredicate
```
java.util.function.BiPredicate<POOLABLE,PooledRefMetadata> evictionPredicate()
```
    A BiPredicate that checks if a resource should be destroyed (true) or is still in a valid state for recycling. This is primarily applied when a resource is released, to check whether or not it can immediately be recycled, but could also be applied during an acquire attempt (detecting eg. idle resources) or by a background reaping process. Both the resource and some metrics about the resource's life within the pool are provided.
  - acquisitionScheduler
```
Scheduler acquisitionScheduler()
```
    When set, Pool implementation MAY decide to use the Scheduler to publish resources in a more deterministic way: the publishing thread would then always be the same, independently of which thread called Pool.acquire() or PooledRef.release() or on which thread the allocator() produced new resources. Note that not all pool implementations are guaranteed to enforce this, as they might have their own thread publishing semantics.
    Defaults to Schedulers.immediate(), which inhibits this behavior.
  - metricsRecorder
```
PoolMetricsRecorder metricsRecorder()
```
    The PoolMetricsRecorder to use to collect instrumentation data of the Pool implementations.
  - clock
```
java.time.Clock clock()
```
    The Clock to use to timestamp pool lifecycle events like allocation and eviction, which can influence eg. the evictionPredicate().

Interface PoolConfig<POOLABLE>

Method Summary

Method Detail

allocator

allocationStrategy

maxPending

releaseHandler

destroyHandler

evictionPredicate

acquisitionScheduler

metricsRecorder

clock