VMware offers training and certification to turbo-charge your progress.Learn more
On behalf of the whole Reactor Team, it is my pleasure to announce that the Reactor
BISMUTH-SR7 release train is now available. As always, we recommend using the
reactor-bom Bill Of Material.
In time for Spring Boot 2, this release train comes with improvements and bugfixes to core, extras, and reactor-netty.
This blog post highlights the most significant changes in both SR7 and last week’s SR6 release trains.
What’s new since
3.1.3? See the full release notes of the
3.1.5.RELEASE. Core changes include more than 15 improvements and bugfixes.
A few new operators have landed in this release: For example,
mergeOrdered has been added to
ParallelFlux. It lets you merge multiple sources by continuously picking the smallest available value among all the sources, as defined by a provided
For convenience, we also added
Mono#thenReturn(T) , allowing easy concatenation/continuation with scalar values.
To kickstart our introspection theme of 2018, our implementations of
Scannable and are thus meaningful when used with
Notable update considerations include the fix of
Mono.zip behavior, aligning it to that of
Flux.zip: It now cancels in-flight sources as soon as one source completes with empty or throws an error. If all the
Mono sources you
zip together are guaranteed to be value, this changes nothing.
If you don’t care about the results but want to make sure the whole of N sources have all completed, prefer using
Mono.when. In particular, look out for a
.zip(…).then() pattern, which should be replaced by
Another change that is less likely to have been noticed by our users is fixing the visibility of a couple of classes that were never intended for the public:
The MPSC Queue implementation from 3.1.3.RELEASE is now exposed only as a plain
Queues.unboundedMultiproducer(). This concrete class is now package-private.
FluxIndexFuseable are now also package-private.
Bug fixes also include a few GC-friendly fixes, stopping unnecessary retaining of
Scheduler workers and event-loop based Processors' background task in case of
What’s new since
3.1.4? See the full release notes of the
Addons has seen a couple of fixes and improvements.
The newly introduced opinionated helper for caching was released with a few package-private interfaces that should have been
public. This is embarrassing. :( It has now been fixed.
Repeat#create factory method variant has been introduced. It allows combining a
Predicate and a maximum amount of repeat attempts.
Repeat and its sister,
Retry, some user noticed that the default behavior feels a bit misaligned with the core’s dumbed-down
retry() variants: Without further configuration, the helpers are capped at a single attempt, where the core versions keep on repeating or retrying. Furthermore, this is changed by chaining in
timeout, which switches to an uncapped attempt behavior (which has been clarified in its javadoc).
We are thinking about realigning this behavior with core in
3.2.0. Please chime in on the issue if you have any insight or feedback.
What’s new since
0.7.3? See the full release notes of the
Reactor-Netty has also seen quite a few fixes, mostly around pooling and the connection lifecycle.
New goodies include support for expect 100-continue, as well as better Reactor
Context handling, by passing Netty pipelines to it when relevant.
Compression support has also been improved, allowing per-response activation of compression. This slightly supersedes the
minCompressionThreshold feature that was already in place (albeit it was not 100% reliable). It is based on a
BiPredicate<Req,Resp> that could, for instance, activate compression only on certain content types. The minimum compression threshold option is backed by a
We encourage you to grab these new artifacts, but, if you’re a Spring Boot user, you’ll be delighted to learn you’ll be rewarded with the same goodies as soon as you upgrade to the upcoming Spring Boot 2.0.0 GA release. :)
As always, feedback is welcome. Come and discuss this release on Gitter or consider opening an issue on GitHub.
In the meantime, happy reactive coding!