vibur / vibur-object-pool Goto Github PK

Consider to implement the AutoCloseable interface to make pool able to be used in "try-with-resources" statements.

The current source code is pretty straight forward:

        for (int i = 0; i < initialSize; i++) {
            available.offerLast(requireNonNull(poolObjectFactory.create()));
            createdTotal.incrementAndGet();
        }

However if creating an pooled object takes one second and the initial size is ten it takes roughly ten seconds for the pool to be initialized. Creating it in parallel could boost the initializing time.

Hi, I'm just going by the description in your maven POM:

<!-- Disruptor dependency will be used only if MultithreadConcurrentQueueCollection
             is injected as a ConcurrentCollection in ConcurrentPool. If the client's application
             wants to use and inject MCQC, it needs to provide the below dependency. -->
        <dependency>
            <groupId>com.conversantmedia</groupId>
            <artifactId>disruptor</artifactId>
            <version>${disruptor.version}</version>
            <scope>provided</scope>
        </dependency>

That means it should have <optional>true</optional> instead of <scope>provided</scope>. With provided scope, you tell maven (and static code analysers) that you have an always-on dependency that you assume will be provided by the end-user. But if I read your comment, it is actually an optional dependency the end-user can provide.

Hi @simeonmalchev,

Firstly, congratulations for your objects pool implementation and thanks for publishing it; it's by far the cleanest & simplest I have found (including Apache Commons').

Here at Caravelo we are trying to use it to implement a connections pool to an Airlines Reservation System.

One of our requirements is that the idle connections must be kept alive before they expire (since they are expensive to create). Pardon me if I'm too naive, but do so I'm thinking of some sort of housekeeping scheduled task which does the following:

1. drain all the idle connections
2. send a keep alive request to the reservation system for each connection
3. return the connections to the pool

I'm aware that Vibur Object Pool supports items validation through the PoolObjectFactory, however I'm afraid this would not be enough to meet the requirement I have just described. Can you provide some advice in this regard?

If it's not possible to do with Vibur Object Pool as of today, I'm thinking of forking the repository, adding housekeeping support (ideally following your indications/specs) and then send you a pull request.

I'll be awaiting your feedback.

Cheers.

If the minimum size for the pool is zero the method tryTake(long, TimeUnit) will create a new pooled "Object". If this creation got stuck the method will not return anything indefinitely.

This is the opposite of the JavaDoc: "@return an object taken from the object pool or {@code null} if the specified timeout expires or if it was interrupted while waiting".
Either the JavaDoc should be edited or the process of object creation should be limited to the waiting period, too.

Hi, nice component,

is there a way to auto remove the object from pool ?

For instance, after 5 seconds that the object is not used check for remove it from the pool and remove it.

Thanks

When I'm closing the pool after usage following exception is thrown:

Caused by: java.lang.Error: Maximum permit count exceeded
	at java.util.concurrent.Semaphore$Sync.tryReleaseShared(Semaphore.java:192)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341)
	at java.util.concurrent.Semaphore.release(Semaphore.java:609)
	at org.vibur.objectpool.ConcurrentPool.terminate(ConcurrentPool.java:405)
	at org.vibur.objectpool.ConcurrentPool.close(ConcurrentPool.java:410)

Pool Creation:

new ConcurrentPool<>(new ConcurrentLinkedQueueCollection<>(), new SourceItemFactory(), 128 * 6, Integer.MAX_VALUE,
            false);

As discussed, vibur-object-pool should call poolObjectFactory.destroy() on returned objects after the pool is terminated in order to avoid potential resource leak.