Threadly Concurrency Overview
Threadly provides a variety of thread pooling designs, ranging from the unique priority based, high performance, thread pools (PriorityScheduler and SingleThreadScheduler for example). To the ability to create a hierarchy of thready pools (sub pools in threadly named “Limiters”, or behavior controlling pool wrappers like the KeyDistributedExecutor. In all cases threadly pools are designed to be safe, able to be garbage collected (or even use the CentralThreadlyPool for when you really don’t want to worry about the pool life cycle).
Beyond the pools, threadly’s ListenableFuture provides a very clean and functional way to implement async callback / transformation operations. Allowing for simple “.map” and “.flatMap” like transformations to provide monad like semantics. In addition tools like FutureUtils helps easily make powerful use of these basic features, as well as tooling when managing collections of futures.
To get a more complete overview of our features take a look at our threadly features wiki page.
Include threadly in your project with the maven coordinates
Threadly Unit Test Overview
Threadly-Test provides utilities to take asynchornous designs and make them easy to unit test deterministicly and quickly. Fitting into the threadly ecosystem is the TestableScheduler which will only execute the provided tasks when
.tick() is invoked. Other examples are the AsyncVerifier and the TestCondition which help in checking async operations, or blocking till an async operation completes as expected.
To get a more complete overview of our test features take a look at our threadly-test features wiki page.
Include threadly-test in your project with the maven coordinates
AuroraArc is an AWS Aurora aware JDBC driver. This JDBC driver takes advantage of Aurora’s rapid failover capabilities. The driver monitors all members in the cluster individually and will distribute requests across the cluster to try and provide the best performance and reliability. This includes using hints from the application to know when requests should be sent to replica servers. It also interpets errors to try and provide degraded service if possible, or otherwise make use of Aurora’s rapid failover capabilities.
Use the mysql AuroraArc driver with the maven coordinates
org.threadly:auroraArc-mysql:0.15 and the postgresql AuroraArc driver with the coordinates
Litesockets provides a high performance non-blocking networking abstraction. It uses the KeyDistributedExecutor to have every individual connections be handled in a single threaded manner. This allows the user to not need to consider concurrency concerns unless using datastructures that are shared by multiple connections.
Litesockets can be included from the maven central coordinates
Threadly 6.4 was released today. This mostly minor release includes a bug fix to the recently added OrderedExecutorLimiter for when returned ListenableFuture’s are canceled. This also includes an improvement to the Profiler to be able to identify idle ForkJoinPool threads. This reduces the output of the profiler for these threads as well as slightly optimizes the memory overhead for tracking these traces.
The above is also summarized in the release notes. There is no new javadocs published for this release as no API changes occurred.
Version 0.15 of auroraArc was released today. This improves the replica weight configuration so that now weights for currently un-known servers can be pre-configured. Hopefully making the feature easier to use by being less precise in when configuration is applied.
In addition version 0.14 was not deployed to maven central correctly. Making the features in 0.14 finally available.
The release artifacts can be pulled from maven central or from our tag: release-0.15.
Threadly 6.3 is another small incremental release that extends the functionality from the 6.2 release. This extends the functoinality in OrderedExecutorLimiter to be able to adjust the limits after construction.
Check the release notes to hear about all of the changes included in this release
The new 0.14 version of auroraArc provides a long wanted feature to be able to weight servers in how they may be randomly chosen. Details about this and the other changes included are listed on the release details.
The ability to set a server weight at runtime allows for a number of new features in how an Aurora cluster can be utilized. The easiest and most obvious use case is if you have a server of a larger instance type. Having weights set to match instance types can allow for more fluid deployment / cluster rotation strategies. It can also make a cluster more stable in a failover condition where the readers and writers are of different types.
This can also be useful in cost and latency optimizations. If you know what availability zone you are in you may choose to set servers in other zones to a weight of ‘0’. Making them only used if there is no healthy servers in your availability zone.
This marks another huge step in providing the unique load and failover capabilities this driver is hoping to provide.
** Update: 0.14 was not deployed to maven central correctly, use 0.15 instead
Threadly 6.2 is fairly minor. Most notably providing the new OrderedExecutorLimiter which provides the first ability for a task sorting besides FIFO. Letting limited / queued tasks to have different sorting logic. Check the release notes to hear about additional minor changes that were included.
Join the discussion by creating an account at https://threadly.zulipchat.com/. We continue to welcome github issues for questions, ideas, or other discussions. But for those who want a more real-time discussion we now have a chat solution setup at Zulip.
Today we released 6.1 of threadly which includes both performance improvements and feature improvements. Most notably is the ability to check error states of ListenableFuture’s without needing to generate an ExecutionException. Check the release notes for more details as well as a list of additional features.
Today we released 6.0 of threadly and 1.0 of threadly-test (which now depends on the new 6.0 threadly). To upgrade check out our major version migration guide, or if you want complete details look at the release notes.
With the removal of our deprecated api’s, and the move of our unit test tools to their own artifact, this notably makes threadly a smaller dependency. Not just caring about jar size, the goal here is that API’s will be easier to navigate to find the features which are useful to you.
We expect 6.X to be shorter lived than 5.X was. Primarily because of the need to migrate off
Unsafe as the JVM continues to drop support for it. However, we needed to be able to update our minimum JVM version to be able to have
Unsafe alternatives. 6.0 consciously had no minimum JVM update (still just requiring 8), but 7.X will have this update so we can continue long term support.
A long overdue replacement of the website. This new site allows us to better provide documentation across all of our libraries and tools. The goal of the change was to be able to provide more documentation and information across our multiple libraries. When the original site was made we really only had one library, we now have networking, a JDBC driver, a load test framework, and I expect even more in the future.
I hope this will be a start of making the site generally more useful. I hope to bring richer news posts, detailing the benchmark results we have been tracking. Not to mention the site now generally has more features (RSS feeds, more pages and structure, etc).
If you have any feedback, or find any problems, please open an issue.
Most notable is the move of the org.threadly.test package to the new threadly-test archive (maven coordinates
org.threadly:threadly-test:0.1). This is planned to be the last release before we switch to the 6.0 API. The release details as always provides complete details on included changes.