Reactor Dysprosium-M1 is Available Now

Releases
Stephane Maldini
May 15, 2019

The 4th Generation of Reactor is arriving. On behalf of the team we want to thank all our community for the tremendous feedback. Over the last year we have grown our reactive line-up significantly including R2DBC and BlockHound. Our adoption in the java ecosystem looks phenomenal and we are collaborating with major corps including Microsoft and Google. We have more than doubled our regular Gitter audience with some awesome -you guessed it- reactive discussions happening every day. Finally, Sergei Egorov has joined the core team and we have no plans to stop expanding!

Dysprosium-M1 is available on our milestone repository. It is paving the way for more changes in the work. It’s worth noting that 2 features are being deprecated, and evaluated for removal at the end of the milestone phase :

EventLoopProcessor => TopicProcessor, WorkQueueProcessor and WaitStrategy : The processors have been moved to reactor-extra for optional use. They require the availability of Unsafe, making them rather niche given modern JVM restrictions. Not only they can be found elsewhere but they can also be replaced by equivalent constructs like EmitterProcessor with publishOn and ParallelFlux with runOn.

Kotlin extensions are being given a dedicated space for further experimentation. With the latest developments around coroutines and inlining, we are excited to evaluate how we can leverage Kotlin to provide a smoother developer experience. One of the goals we have set to this experiment is to provide a dedicated API that will enable writing custom producers and operators with the conciseness of Kotlin.

Even with these changes we do not anticipate major pains for our community, but we’d like to have your opinion.

Change logs and release notes:

• reactor-core 3.3.0.M1
• reactor-netty 0.9.0.M1
• reactor-addons 3.3.0.M1
• BlockHound 1.0.0.M3
  Runtime performances

We are working hard at improving the overall experience for our users and upgrading our runtime efficiency across the board:

• reactor-netty 0.9.0.M1/0.8.8 has seen a 40% throughput improvement for request/reply (HTTP) scenarios and at least 20% increase for streaming scenarios. More importantly, memory management has been tightened to control some reported memory issues and the number of required flush operations has been dramatically reduced (3x less) which is a welcome news for CPU use.
• For reactor-core 3.3.0 , we are looking at progressively moving debugging interceptors outside of the critical path using an agent based approach.
  Bismuth EOL

Anticipating the coming Dysprosium-RELEASE, our reactor-core 3.1.x and reactor-netty 0.7.x lines will not receive further patches. We encourage our users to update to Californium releases trains, which match Spring Boot 2.1.x and Spring Framework 5.1.x.

If you already are using Spring Boot 2.2.x and Spring Framework 5.2.x, you will be required to use Dysprosium including reactor-core 3.3.x and reactor-netty 0.9.x.
Trivia

What is Dysprosium ? Well its a chemical element starting with the 4th letter of the latin alphabet. It also means “hard to get” because it took quite a few attempts to isolate it. So, mark my words, everything should be ok with Dysprosium.

Again, we appreciate your valuable input, please join us on Gitter and share your question, story or both! Meanwhile, we are sailing towards a second milestone early June.

Project Page | GitHub | Documentation | Stack Overflow | Gitter
comments powered by Disqus

translate：
翻译：

第四代反应堆即将到来。我们谨代表团队感谢我们全体社区的巨大反馈。在过去的一年中，我们的反应式阵容显着增长，包括R2DBC和BlockHound。我们在Java生态系统中的采用看起来是惊人的，并且我们正在与包括Microsoft和Google在内的主要公司合作。我们每天在Gitter上进行的精彩讨论（您猜对了），使我们的常规Gitter受众增加了一倍以上。最后，谢尔盖·伊戈罗夫（Sergei Egorov）已加入核心团队，我们没有停止扩张的计划！

miles M1可在我们的里程碑资料库中找到。它为工作中的更多变更铺平了道路。值得注意的是，在里程碑阶段结束时，已经弃用了2个功能，并评估了它们的删除能力：

EventLoopProcessor => TopicProcessor，WorkQueueProcessor和WaitStrategy：处理器已移至“额外反应器”以供可选使用。他们需要使用Unsafe，因此在现代JVM限制下，它们的位置相当狭窄。不仅可以在其他地方找到它们，还可以用等效的结构（例如带有publishOn的EmitterProcessor和带有runOn的ParallelFlux）代替它们。

Kotlin扩展程序已获得专用空间，可以进行进一步的实验。随着协程和内联技术的最新发展，我们很高兴评估如何利用Kotlin提供更顺畅的开发人员体验。我们为此实验设定的目标之一是提供专用的API，使编写具有Kotlin简洁性的自定义生产者和操作员成为可能。

即使进行了这些更改，我们也不会为我们的社区带来重大麻烦，但我们希望收到您的意见。