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

Threadly 6.2 released

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.

Chat on Zulip

Today we are happy to announce another option for getting in touch with us. 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.

Join us by creating an account at https://threadly.zulipchat.com/. Some points of interests are the announcements stream where we will provide alerts on version releases. In general this stream should match fairly close to when there is a post on the website.

We also have a stream for every threadly project. On signing up you will be added to the more popoular projects, but others can be joined manually if interested. For each project stream feel free to start a topic for your question, idea for improvement, or anything else you want to talk about.

I would like to try moving some API discussions here instead of on github issues. If API ergonomics interest you I recommend watching both github and joining Zulip.

Threadly 6.1 released

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.

Threadly 6.0 and threadly-test 1.0 released

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.

Website Redesign

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.

Threadly 5.43 and threadly-test 0.1 released

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.

Threadly 5.42 released

This release provides performance improvements to RateLimiterExecutor and ExecutorLimiter. The gains in RateLimiterExecutor being most significant, providing huge improvements in cases where thread contention exists.

AuroraArc 0.13 released

The newly released 0.13 of auroraArc marks a notable improvement in reliability when a replica is an unhealthy state but being unused. It adds additional state setting cases to the connections which it ignores. When the connection is actually used for a query or other server side change then the error will be thrown.

Threadly 5.41 released

Another 5.X release focused primarily on performance improvements and other internal updates. The release details outlines the specific areas of improvement.

Threadly 5.40 released

As we start to think more about a 6.0 release, backwards compatible API changes have been provided in the new 5.40 release. In this we moved and renamed Watchdog into the new watchdog package. As part of this we also added a new “PollingWatchdog” to be able to provide more flexible timeout mechanics when desired.

RSS Subscribe


See more posts from the News Archive.