A fast object pool for the JVM

This makes it easy to compose Expirations.

Not sure if it make sense to include this in the core stormpot, but if you think it does, here is the code. It is useful for me, it might be for someone else ...

I just noticed that Stormpot preemptively allocates in the background until the target size has been met. Can this be turned off so that the objects are lazily allocated (ie. when a claim comes in and size < targetSize then allocate new object)?

I'm pooling short-lived server connections and I really don't want these to be allocated by Stormpot on the first claim, especially at times they're not needed.

Pools, or the QueuePool at least, should be able to take an Executor or similar through the Config. The Executor should be used instead of the allocation thread. I'm not entirely sure why this is a brilliant idea, but Viktor Klang thought it was important for Journal.IO, so it might also be important here. I should probably ask him about it.

It was discovered during a benchmark run, that the Whirlpool implementation can deadlock when you await the completion of the shutdown procedure.

Thread dump:

"Whirlpool-Allocator-Thread for stormpot.benchmark.PoolSpin$SlowAllocator@11f2ee1" prio=10 tid=0x780d7800 nid=0x773c runnable [0x778fe000]
   java.lang.Thread.State: TIMED_WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x7c4f0358> (a stormpot.whirlpool.Request)
  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
  at stormpot.whirlpool.Request.await(Request.java:53)
  at stormpot.whirlpool.Whirlpool.perform(Whirlpool.java:220)
  at stormpot.whirlpool.Whirlpool.relieve(Whirlpool.java:145)
  at stormpot.whirlpool.WpAllocThread.deallocateAll(WpAllocThread.java:132)
  at stormpot.whirlpool.WpAllocThread.run(WpAllocThread.java:69)

   Locked ownable synchronizers:
  - None

"main" prio=10 tid=0x0978c800 nid=0x7731 waiting on condition [0xb6a92000]
   java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x7c5298b0> (a java.util.concurrent.CountDownLatch$Sync)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
  at stormpot.whirlpool.WpAllocThread.await(WpAllocThread.java:53)
  at stormpot.benchmark.PoolSpin.tearDown(PoolSpin.java:84)
  at stormpot.benchmark.ContendedPoolSpin.tearDown(ContendedPoolSpin.java:54)
  at com.google.caliper.SimpleBenchmark$1.close(SimpleBenchmark.java:139)
  at com.google.caliper.TimeMeasurer.measureReps(TimeMeasurer.java:177)
  at com.google.caliper.TimeMeasurer.warmUp(TimeMeasurer.java:62)
  at com.google.caliper.TimeMeasurer.run(TimeMeasurer.java:122)
  at com.google.caliper.InProcessRunner.run(InProcessRunner.java:74)
  at com.google.caliper.InProcessRunner.run(InProcessRunner.java:49)
  at com.google.caliper.InProcessRunner.main(InProcessRunner.java:103)

   Locked ownable synchronizers:
  - None

See test case added as 0484a6afbd13bdf3d11a48a3d481061cafd475bb in https://github.com/simongibbsft/stormpot/tree/2.1

This demonstrates that in some scenarios an exception raised during allocation of a new poolable can be propagated to clients on more than one occasion.

In our logs we can see timestamped exception objects being rethrown over very long periods, causing a brief outage of the dependee system to become artificially long-lived requiring a sysop to reboot the dependant system.

I'm trying to use stormpot 2.4.1 for a project and ran into an issue where in objects are not deallocated after pool shutdown. Initially, I thought it was an issue with how I'm using stormpot and that objects are being leaked in my application, but later I managed to repro it through a simple test

Here's what I'm trying to do:

1. Maintain a map of id -> StormPot pool, where each pool has about 16 objects in steady state
2. At some point, I figure out that I need to recreate a pool for a given id, at which point I do

BlazePool p = poolMap.get(id); Completion c = p.shutdown(); c.await(new Timeout(100, TimeUnit.MILLISECONDS)); poolMap.put(id, new BlazePool(config));

3. The actual logic is a little more complicated since I can have unreleased objects at the time of pool shutdown, and I handle it in the application (the object has a reference to the pool so that I can release it to the pool).

4. In the normal (pool is not shutdown) case, I do either of the following in order to release an object back to the pool (depending on the state of the object).

slot.release(this); OR slot.expire(this); slot.release(this);

The issue I'm seeing is that whenever I expire + release a claimed object, and follow it up by shutting down the pool, the released object is never de-allocated.

I reproduced the issue in a simple test by doing the following

1. create 2 pools, one BlazePool and one QueuePool
2. claim an object from each pool
3. expire+release the object back to the respective pools
4. shutdown both pools and await for 10 seconds

I observed that only the released QueuePool object is deallocated, the BlazePool object is never deallocated. Also, this issue does not show up when I replace (expire + release) with a simple (release).

Please let me know if you need any additional information.

I'm actually using Stormpot to build a socket client pool. I need to ensure that every claimed object is a Poolable that is connected to a server. So first I test the connection by sending a simple message to the server, and if it gets and exception I mark it as invalid. I repeat it until I get a valid object (conneted to the server). You can see that if there are 50 objects in the pool, I will have to test 50 times... Is there any way to get the newly allocated object instead of another object in the pool? This way I will have to test only once.

A lot of contention in the QueuePool implementation comes from the use of blocking queues.

Another non-blocking live-queue could be added as a fast-path option: claims would take from the non-blocking live-queue first, and only if it turns out to be empty, try to take from the blocking live-queue (with timeout logic, etc.)

The blocking live-queue will have to be bounded such that it is smaller than the maximum number of elements in the pool. Since the pool is resizable, the only real option for a bound is 1.

It must be bounded, because the allocation thread will have to release new live objects into the blocking live-queue first, and only if it's full, insert them into the non-blocking live-queue. This way, we ensure that if the pool has been depleted, the new object will allow a thread waiting in claim to make progress.

Style is now check during build at verify phase. Configuration is minimal and only checks for 2-space indentation at the moment. It can obviously be extended as required.

Build will fail if violations are found.

fixes #97

I'm trying to create an pool-agnostic poolable resource and one thing I bump into that is not a big issue, but kinda ugly, is that Poolable defines release vs. close. Personally, I would like it if Poolable implemented AutoClosable with #close instead of #release. I'm not sure if there was a reason for this or if it is just legacy but it seems like if you are pooling Database Connections, Sockets, Files, or Redis Clients, you are going to want to have the typical #close method delegate to your #release.

Not a big deal, and I wouldn't want you to break backwards compatibility but I just thought I'd mention it.

As-is these revisions will cause the build to fail due to an error hanling this scenario:

• Server starts up and creates it's back end, inlcuding a pool.
• Server creates its front end, including Jetty bound to a port.
• Server set up fails as the port is already bound.
• Server handles the failure, including calling pool.shutdown()

Expected behaviour:

• Process exits cleanly.

Actual behaviour.

• The allocator thread remains open, preventing the JVM from terminating.

The revisions expose the problem in a unit test and add minor feature to assign predictable names to threads (which can then be asserted on).

Hi chrisvest/stormpot!

This is a one-off automatically generated pull request from LGTM.com :robot:. You might have heard that we’ve integrated LGTM’s underlying CodeQL analysis engine natively into GitHub. The result is GitHub code scanning!

With LGTM fully integrated into code scanning, we are focused on improving CodeQL within the native GitHub code scanning experience. In order to take advantage of current and future improvements to our analysis capabilities, we suggest you enable code scanning on your repository. Please take a look at our blog post for more information.

This pull request enables code scanning by adding an auto-generated codeql.yml workflow file for GitHub Actions to your repository — take a look! We tested it before opening this pull request, so all should be working :heavy_check_mark:. In fact, you might already have seen some alerts appear on this pull request!

Where needed and if possible, we’ve adjusted the configuration to the needs of your particular repository. But of course, you should feel free to tweak it further! Check this page for detailed documentation.

Questions? Check out the FAQ below!

FAQ

issue #148 feature request for more metrics initial first stab

Project tests wouldn't run on the java 11 version I had without the pom upgrades

I've not worked out testing yet

Though the current metrics are useful we'd really like to see how many connections are in the pool and how many are available/in use.

We'd use this to:

1/ actual pool size - see if there were some allocation problem - e.g. the pool collapses due to some network or other problem

2/ pool available connections - see trends in available connections for tuning - reducing if we've over provisioned and increasing if we're near the limit - I guess the average time to get a connection from the pool might imply we've started to hit a pool size issue but it's not quite the same as being able to see the trend before we hit increases in getting a connections

This is a temporary solution to compile natively using GraalVM (#143). Does not affect any other scenario. May be removed when this issue is solved: https://github.com/oracle/graal/issues/3028

I'm trying to compile stormpot jar with my application using GraalVM native-image compiler, and I'm getting only 2 errors, that looks simple to resolve.

Error: Unsupported features in 2 methods
Detailed message:
Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: VarHandle object must be a compile time constant
Trace: 
        at parsing stormpot.PaddedAtomicInteger.compareAndSet(BSlot.java:190)
Call path from entry point to stormpot.PaddedAtomicInteger.compareAndSet(int, int): 
        at stormpot.PaddedAtomicInteger.compareAndSet(BSlot.java:190)
        at stormpot.BSlot.live2dead(BSlot.java:98)
        at stormpot.BAllocThread.shutPoolDown(BAllocThread.java:242)
        at stormpot.BAllocThread.run(BAllocThread.java:90)
        at java.lang.Thread.run(Thread.java:834)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
        at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
        at com.oracle.svm.core.code.IsolateEnterStub.PosixJavaThreads_pthreadStartRoutine_e1f4a8c0039f8337338252cd8734f63a79b5e3df(generated:0)
Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: VarHandle object must be a compile time constant
Trace: 
        at parsing stormpot.PaddedAtomicInteger.lazySet(BSlot.java:194)
Call path from entry point to stormpot.PaddedAtomicInteger.lazySet(int): 
        at stormpot.PaddedAtomicInteger.lazySet(BSlot.java:194)
        at stormpot.BSlot.dead2live(BSlot.java:82)
        at stormpot.BAllocThread.continuouslyReplenishPool(BAllocThread.java:105)
        at stormpot.BAllocThread.run(BAllocThread.java:89)
        at java.lang.Thread.run(Thread.java:834)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
        at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)
        at com.oracle.svm.core.code.IsolateEnterStub.PosixJavaThreads_pthreadStartRoutine_e1f4a8c0039f8337338252cd8734f63a79b5e3df(generated:0)

It's solved using a native-image.properties file with an argument to initialize this class at compile time: Args = --initialize-at-build-time=stormpot.PaddedAtomicInteger

But I think that maybe it's better to remove the using of VarHandle feature. Is it really necessary?

Stormpot is going great for my Load Balancer but sometimes during peak usages, the object pool is hitting 1.2B objects. Stormpot uses int so the maximum object pool size is limited to 2B.

Do we have plans to support a larger object pool (greater than 2B) using long?