A collection of java libraries to assist with development of java services to help bring new levels of safety, performance, and reliability.concurrent java applications. Ranging from concurrency tools designed to complement to java.util.concurrent, unit testing tools, NIO netwrking, AWS Aurora JDBC driver.

Threadly Concurrency Overview

Build status

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 org.threadly:threadly:6.6.

Threadly Unit Test Overview

Build status

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 org.threadly:threadly-test:1.0.

AuroraArc Overview

Build status

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 org.threadly:auroraArc-psql:0.15.

Litesockets Overview

Build status

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 org.threadly:litesockets:4.14.


AuroraArc 0.16 released

Yesterday AuroraArc version 0.16 was released to maven central. This version only includes an update of our dependent artifacts. Notably this requires the minimum supported JVM version to be increased to 11+, but also brings in compatibility with JDK17.

Speaking broadly AuroraArc is basically ready for a 1.0 release. However I have not had been able to do as much testing on it recently as I would like. If anyone is making use of this driver we would really like to collaborate and make sure the project remains stable and useful.

Threadly 7.0 released

We released the next major version of Threadly today. 7.0 brings in support for JDK 17, as well as some performance improvements with ListenableFutures and the mapping of futures. You can read more about these changes and API’s which were deprecated in this release in the release notes.

The Migration Guide has also been updated with instructions to update to the 7.0 release version. As always if you are running the latest version (6.7) with no depreciated API warnings, then the next major version should be able to be updated without issue. If you find you need help migrating or using Threadly 7.0 feel free to join us on the Zulip Chat or file an issue on GitHub.

Threadly 6.7 released

We released Threadly 6.7 today. This release is primarily in prep for a future 7.0 major version. Notably the implementation of ListenableFutureTask will be changing in order to support the removal of UnsafeAccess for JDK 17+ support. In 7.0 we no longer will be supporting ListenableFutureTasks to be used in a recurring fashion. This was not a feature used by Threadly (the concept is awkward with ListenableFuture’s), but is used by our compatibility layer. The comparability layer will continue to function in 7.0 normally but ListenableFutureTask will not have a public API that allows for recurring usage.

As always, if you are using our last version with no depreciated API’s, this should indicate an upgrade to the next major version with no other needed changes.

You can read more about this release in the release notes.

Threadly Project Status Update

You may have noticed that over the last year activity on the project has reduced. Despite reducing, this project is still supported with future development planned.

Since our first release of Threadly in February 2014 the project has seen a wide range of expansion and improvements. The initial versions including significant API and even perspective changes as Threadly became incorporated in new use cases.

More recently with Threadly 6.X versions, and even changes towards the end of the 5.X branch, the project has become much more stable. Changes being more minor bug fixes or minor feature improvements. This has really been a representation of how the project has been gaining maturity. Usage of threadly has continued, and similarly support is also expected to continue. The current major version 6.X has been active for over a year, although with notably fewer releases. We are expecting to release 7.0 within the next year which will supply the removal of current deprecated API’s (Notably UnsafeAccess). This will also include the implementation of issue 256 to avoid the current needed access hack which may not be supported in future JVM versions. This work has been started, but not completed as currently there are...

Threadly 6.6 released

Threadly 6.6 was released today. This release provides improvements to FutureUtils and StatisticUtils. These changes are fairly minor as development has recently been more stable and slower. I still have plans for more significant changes (as described in GitHub issues), but recently I have had less time to work on this project.

You can read more about this release in the release notes.

Threadly 6.5 released

Threadly 6.5 was released today. This release provides improvements to ReschedulingOperation and ConfigurableThreadFactory.

ReschedulingOperation got an internal performance improvement to avoid re-queuing through the executor if it was signaled to run while it was currently executing. Instead looping on the thread it already has (for a limited number of loops). This provides a notable performance improvement by avoiding to re-queue through the executor, but it can also prevent a stack overflow when SameThreadSubmitterExecutor is used.

ConfigurableThreadFactory now additionally has the ability to configure a Consumer to accept threads as they are created. This can be useful to provide additional custom logic for each thread. Notably this can be useful for tracking threads for debugging purposes, like when ControlledThreadProfiler is used.

You can read more about this release in the release notes.

Threadly 6.4 released

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.

AuroraArc 0.15 released

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 released

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

AuroraArc 0.14 released

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

</div> [news]: news.html [https:threadly.zulipchat.com]: https:threadly.zulipchat.com [https:github.comthreadlythreadlywiki]: https:github.comthreadlythreadlywiki [https:github.comthreadlythreadly]: https:github.comthreadlythreadly [https:github.comthreadlythreadly-test]: https:github.comthreadlythreadly-test [https:github.comthreadlyauroraArc]: https:github.comthreadlyauroraArc [https:github.comthreadlylitesockets]: https:github.comthreadlylitesockets [https:github.comthreadlyambush]: https:github.comthreadlyambush [javadocsthreadly7.0]: javadocsthreadly7.0 [javadocsthreadly-test1.0]: javadocsthreadly-test1.0 [javadocslitesockets4.14]: javadocslitesockets4.14 [javadocsambush0.2]: javadocsambush0.2 [https:github.comthreadlythreadlyreleasesdownloadrelease-7.0threadly-7.0.jar]: https:github.comthreadlythreadlyreleasesdownloadrelease-7.0threadly-7.0.jar [https:github.comthreadlythreadly-testreleasesdownloadrelease-1.0threadly-test-1.0.jar]: https:github.comthreadlythreadly-testreleasesdownloadrelease-1.0threadly-test-1.0.jar [https:github.comthreadlylitesocketsreleasesdownloadrelease-4.14litesockets-4.14.jar]: https:github.comthreadlylitesocketsreleasesdownloadrelease-4.14litesockets-4.14.jar [news]: news