A library of java tools to assist with development of concurrent java applications. This is designed to be a complement to java.util.concurrent to provide functionality more tools for making safe concurrent implementations.
This library 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.
This library not only helps with providing tools to design safe and easy to understand designs, but also includes utilities for making it easier to unit test and debug concurrent implementations.
To get a more complete overview of our features take a look at our features wiki page.
* May 23rd - 5.37 Release to include new features around queue consumption and work processing. See the new package org.threadly.concurrent.processing and the release details.
* March 28th - 5.36 minor release to provide complete protection against Exception cause cycles for ExceptionUtils.
* Match 26th - 5.35 release with the added FilteredStackProfiler as an additional Profiler implementation.
* March 13th - 5.34 released with significant changes to the ListenableFuture API. Defined in the release details, the most significant changes are the deprication of `addCallback` and `addListener`. Now providing more functionality with a `callback` and `listener` function that return the instance, as well as a `resultCallback` and `failureCallback` function for when there is only one state needing checked.
* Febuary 13th - Patch release to fix safe point loss in PriorityScheduler workerIdle tight loop, and other minor improvements. Read about them in the release details.
* January 9th - Another minor release to add a couple features (some external, some internal for other threadly projects). Read about them in the release details.
* December 30th - Minor release 5.30 published to maven central. This includes a bug in Clock as well as improvements in FutureUtils when converting a collection of ListenableFuture's into a single result future. Read about them in the release details.
* November 1st - Bug fix release 5.29 to provide improvements when mapping futures (either with .map or things like FutureUtils.executeWhile). Changes are focused around stack trace communication, and propagating future cancellations to ensure unnecessary processing does not go un-interrupted.
* October 1st - 5.28 released with several improvements around ListenableFuture's. Described in detail on the changelog, this release includes a minor bugfix around canceling flatMap'ed futures, as well as significant debugging improvements. This release provides the ability to get the stack of a running future (or if a mapped future waiting on a result, the stack of the currently executing parent future).
* July 3rd - 5.27 was released which includes minor changes to further the improvement introduced in 5.26.
* July 1st - 5.26 was released, providing minor internal performance improvements to PriorityScheduler, and heap improvements when adapting DoNothingRunnable's into Callable's.
* June 19th - 5.25 was released. This contains a number of internal improvements and external improvements. Read about them in the release details.
* May 25th - 5.23 was released. Threadly has been getting a lot of attention lately. This release does include a small bug fix for the Profiler when used with the `SameThreadSubmitterExecutor`. However this release is focused mostly around improvements, performance improvements with futures and other minor improvements.
* May 21st - 5.22 was released as a follow up to the bug fix in 5.21. Not a recent regression, just another case of the defect that was missed.
* May 20th - 5.21 was released, focused around another bug fix around canceling collections of Futures produced by FutureUtils. We also now are using buildkite to perform our CI solution. Having talked with them I am pretty confident this will be a better fit for our needs.
* May 18th - 5.20 was released which includes important bug fixes for communicating the "canceled" state after a map / flatMap operation on a future. It also includes internal performance improvements and minor features expansions (which can be read about in the changelog).
* May 15th - Following closely behind 5.18, 5.19 provides internal improvements as well as minor features that can be read about in the changelog.
* May 4th - A feature expansion release of 5.18 was published to maven central today. The primary feature in this release is the add of `mapFailure` and `flatMapFailure` to `ListenableFuture`. These functions allow you to async transform futures from the error conditions back into results or into different error conditions.
* April 20th - 5.16 was released today. I had planned for 5.16 to be a feature expansion release. I have been working on a new sub-pool that will help threadly's central pool. However it's not ready yet. Instead this release contains a bug fix for the central pool where `isolatedTask` recurring tasks could decrement the central pools size after every run, eventually resulting in logging exceptions as the pool tries to shrink itself below zero. This critical bug fix pushed the release forward. But I am also excited to announce a new feature in FutureUtils. Now in addition to `scheduleWhile` there is `executeWhile`. This is more flexible to other pool types (as it does not even require a pool, just a `ListenableFuture`). It is conceptually the same, except where a delay for retry is not desired.
* March 6th - 5.15 was released today with new features, improvements, and some small bug fixes. All the details can be found in the Release notes.
* February 16th - 5.14 minor release with new StringUtils functionality and javadoc improvements.
* February 4th - 5.13 incremental improvements release. Release notes contain all the details, but this includes a variety of small incremental improvements. Typically not enough to warrant a release, with 5.X we plan to have more small releases like this.
* January 22nd - 5.12 bug fix release for unlikely, but possible, race condition when using the new ListenableFuture listener execution optimizations introduced in 5.10.
* January 17th - 5.11 release to provide pre-5.10 functionality when mapping ListenableFutures as `throwMap`. It was discovered that there is good reason to sometimes have the mapper function throw an exception, and that those should not be treated as "uncaught" exceptions. The default behavior of `map` will still report the exception to `ExceptionUtils.handleException`, since that is the behavior most people probably expect. But `throwMap` was added to facilitate the rare use case where you want / expect an exception to be thrown.
* January 16th - 5.10 release to include more minor bug fixes, as well as the opportunity to further optimize listeners being executed on `ListenableFuture`'s. Read more in the ListenableFuture.ListenerOptimizationStrategy javadocs.
* January 5th - Patch release to fix very old bug in `StripedLock`.
* December 28th - Released some new minor features in threadly version 5.8.
* December 19th - Released version 5.7. This is a fairly significant feature expansion release. Allowing limiters to not be impacted by the listener (monads) execution if desired. As well as the newly added `CentralThreadlyPool`. Allowing the limiters to not limit listeners / map functions allows you to be sure you are limiting a core task functionality, and not also including limits towards operations which may occur after that core task completes. The `CentralThreadlyPool` allows you to gain access to a scheduler / executor for the immediate needs, without having to worry about a scheduler life cycle (ie shutting down). Internally this pool will try to reduce thread churn as much as possible while also making sure that the threads are available for the task demand requested (and not letting any single scheduler fully take control over the pool). This feature has been one in the works for a while, and I am pretty happy with how it came out, so I highly encourage you to look at it!
* November 27th - Released version 5.6 which includes minor quality of life improvements as well as improvements to canceling futures from threadly monads. As always the details are included in the full release notes.
* October 31st - Patch version 5.5 to address low priority tasks not completing on scheduler shutdown. There is no javadocs for this release due to there being no API changes.
* October 21st - Incremental version released, version 5.4 is now in maven central.
* July 22nd - Released version 5.2 that includes performance improvements in ListenableFuture/RunnableListenerHelper and ExecutorLimiter. Changes are mostly simple, but with 5.X we plan to release more frequent but smaller releases. Because of that we are trying to reduce some extra processes.
* July 2nd - Patch version 5.1 fixes regression in 5.0 PriorityScheduler where threads may forever go idle. This is a regression due to an optimization when interactions with other blocking actions using LockSupport. It is critical that all 5.0 usage is upgraded to use version 5.1 or newer.
* June 28th - After months of work, released version 5.0! This is easily the best threadly yet. It does require the use of java 8 and newer, but that means we are also able to take advantage of java 8 performance improvements and ergonomic improvements. I have been hesitant to release this because there is still so much more I want to do. Other projects like auroraArc have been taking more of my time. That said, I do plan to bring some improved documentation and benchmarks out soon. Right now the wiki is the best source of information, but if anyone would like to help improve this website it would be greatly appreciated!.