{"id":421019,"date":"2024-06-30T03:49:56","date_gmt":"2024-06-30T03:49:56","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=421019"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=421019","title":{"rendered":"Spring Reactor Mono::block deadlock<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n
\"And<\/p>\n
And where is the deadlock here?<\/figcaption><\/div>\n<\/figure>\n

Faced with the situation when calling Mono::block leads to deadlock<\/strong> — in debug I can just see how it stands on Unsafe::park and no more movement at all.<\/p>\n\n

Actually this is the code example with described problem.<\/p>\n

Flux<PojoClass> pojoClassFlux = Flux.fromIterable(pojoClassSet);  pojoClassFlux         .groupBy(PojoClass::getInteger)         .map(pojoClassIntegerGroupedFlux -> pojoClassIntegerGroupedFlux                 .map(pojoClass -> {                     \/\/some mapping                 })                 .reduce(new PojoClassIntegerGroup(), (currentPojoClassIntegerGroup, newSourceFilterToColumn) -> {                     \/\/some reduce function                 })         )\/\/ <-- Flux<Mono<PojoClassIntegerGroup>>         .reduce(new PojoClassIntegerAllGroup(), (currentPojoClassIntegerAllGroup, newPojoClassIntegerGroupMono) -> {                     PojoClassIntegerGroup newPojoClassIntegerGroup = newPojoClassIntegerGroupMono                             .block();\/\/ <-- here is the DEADLOCK!                     \/\/ do something with newPojoClassIntegerGroup for reduce                 }         )         .subscribe(\/\/do something,                 throwable -> {                     \/\/throw the problem                 },                 () -> log.info(\"SUCCESS\")         ); <\/code><\/pre>\n
So, at the point of newPojoClassIntegerGroupMono.block()<\/strong> of my example, I got stack of JVM awaiting for something at Unsafe::park<\/strong> method.<\/p>\n
\"Continuous<\/p>\n
Continuous awaiting at Unsafe::park<\/strong> method.<\/figcaption><\/div>\n<\/figure>\n
And it happens nothing after awaiting for some time — the debug point not moving at all. For current example it was used next version of reactor-core dependency in pom.xml:<\/p>\n
<dependency>     <groupId>io.projectreactor<\/groupId>     <artifactId>reactor-core<\/artifactId>     <version>3.3.10.RELEASE<\/version> <\/dependency><\/code><\/pre>\n
Here you can find the link to registered issue at GitHub for reactor-core:<\/p>\n
\n
https:\/\/github.com\/reactor\/reactor-core\/issues\/1651<\/a><\/p>\n<\/blockquote>\n
\n
But how can we solve our case now?<\/p>\n<\/blockquote>\n
We can use Flux::flatMap<\/strong> instead of Flux::map<\/strong> function after groupBy. And then our code example become like below — it works!<\/p>\n
pojoClassFlux         .groupBy(PojoClass::getInteger)         .flatMap(pojoClassIntegerGroupedFlux -> pojoClassIntegerGroupedFlux \/\/ <-- flatMap here                 .map(pojoClass -> {                     \/\/some mapping                 })                 .reduce(new PojoClassIntegerGroup(), (currentPojoClassIntegerGroup, newSourceFilterToColumn) -> {                     \/\/some reduce function                 })         )\/\/ <-- Flux<PojoClassIntegerGroup> here after flatMap         .reduce(new PojoClassIntegerAllGroup(), (currentPojoClassIntegerAllGroup, newPojoClassIntegerGroup) -> {                     \/\/do something with the newPojoClassIntegerGroup for reduce -- no need for Mono::block!                 }         )         .subscribe(\/\/do something with final PojoClassIntegerAllGroup,                 throwable -> {                     \/\/throw the problem                 },                 () -> log.info(\"SUCCESS\")         ); <\/code><\/pre>\n
Using Flux::flatMap<\/strong> here, we will remove passing of unnecessary Mono inside of Flux at final reduce step — it will be just Flux<PojoClassIntegerGroup> — what we need!<\/p>\n
At least if there is a need to work with the result — it can be used Mono::subscribe<\/strong> to set some AtomicReference field<\/strong> with the result of Mono, instead of Mono::block directly. See example below:<\/p>\n
AtomicReference<MyBestPojoClass> myBestPojoClassHolder = new AtomicReference<>(); pojoClassMono.subscribe(myBestPojoClassHolder::set);<\/code><\/pre>\n\n
It is better not to call blocking operation in general and Mono::block particularly at all when working with Spring Reactor. This example demonstrates how it could lead to deadlock. In this case you can see how Flux::flatMap removes Mono inside of Flux<Mono<PojoClassIntegerGroup>> — and we can work directly with returned type without calling blocking method. If very needed to extract the result of Mono then try Mono::subscribe <\/strong>to set the field as described above in this article. If you have your own recipe of how to avoid call to block in some cases with Reactor — please feel free to write comments here.<\/p>\n
If you have what to say about the topic and want to give negative rating — please feel free to write your comments to understand your opinion. Otherwise it is not serious and it is not clear why you vote negatively.<\/p>\n
And of course If you like this article, please vote UP — this will support me to write more such posts with real code examples!<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/741464\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
\n
\n
\n
\n
\n
And where is the deadlock here?<\/figcaption><\/div>\n<\/figure>\n
Faced with the situation when calling Mono::block leads to deadlock<\/strong> — in debug I can just see how it stands on Unsafe::park and no more movement at all.<\/p>\n\n
Actually this is the code example with described problem.<\/p>\n
Flux<PojoClass> pojoClassFlux = Flux.fromIterable(pojoClassSet);  pojoClassFlux         .groupBy(PojoClass::getInteger)         .map(pojoClassIntegerGroupedFlux -> pojoClassIntegerGroupedFlux                 .map(pojoClass -> {                     \/\/some mapping                 })                 .reduce(new PojoClassIntegerGroup(), (currentPojoClassIntegerGroup, newSourceFilterToColumn) -> {                     \/\/some reduce function                 })         )\/\/ <-- Flux<Mono<PojoClassIntegerGroup>>         .reduce(new PojoClassIntegerAllGroup(), (currentPojoClassIntegerAllGroup, newPojoClassIntegerGroupMono) -> {                     PojoClassIntegerGroup newPojoClassIntegerGroup = newPojoClassIntegerGroupMono                             .block();\/\/ <-- here is the DEADLOCK!                     \/\/ do something with newPojoClassIntegerGroup for reduce                 }         )         .subscribe(\/\/do something,                 throwable -> {                     \/\/throw the problem                 },                 () -> log.info(\"SUCCESS\")         ); <\/code><\/pre>\n
So, at the point of newPojoClassIntegerGroupMono.block()<\/strong> of my example, I got stack of JVM awaiting for something at Unsafe::park<\/strong> method.<\/p>\n
\n
Continuous awaiting at Unsafe::park<\/strong> method.<\/figcaption><\/div>\n<\/figure>\n
And it happens nothing after awaiting for some time — the debug point not moving at all. For current example it was used next version of reactor-core dependency in pom.xml:<\/p>\n
<dependency>     <groupId>io.projectreactor<\/groupId>     <artifactId>reactor-core<\/artifactId>     <version>3.3.10.RELEASE<\/version> <\/dependency><\/code><\/pre>\n
Here you can find the link to registered issue at GitHub for reactor-core:<\/p>\n
\n
https:\/\/github.com\/reactor\/reactor-core\/issues\/1651<\/a><\/p>\n<\/blockquote>\n
\n
But how can we solve our case now?<\/p>\n<\/blockquote>\n
We can use Flux::flatMap<\/strong> instead of Flux::map<\/strong> function after groupBy. And then our code example become like below — it works!<\/p>\n
pojoClassFlux         .groupBy(PojoClass::getInteger)         .flatMap(pojoClassIntegerGroupedFlux -> pojoClassIntegerGroupedFlux \/\/ <-- flatMap here                 .map(pojoClass -> {                     \/\/some mapping                 })                 .reduce(new PojoClassIntegerGroup(), (currentPojoClassIntegerGroup, newSourceFilterToColumn) -> {                     \/\/some reduce function                 })         )\/\/ <-- Flux<PojoClassIntegerGroup> here after flatMap         .reduce(new PojoClassIntegerAllGroup(), (currentPojoClassIntegerAllGroup, newPojoClassIntegerGroup) -> {                     \/\/do something with the newPojoClassIntegerGroup for reduce -- no need for Mono::block!                 }         )         .subscribe(\/\/do something with final PojoClassIntegerAllGroup,                 throwable -> {                     \/\/throw the problem                 },                 () -> log.info(\"SUCCESS\")         ); <\/code><\/pre>\n
Using Flux::flatMap<\/strong> here, we will remove passing of unnecessary Mono inside of Flux at final reduce step — it will be just Flux<PojoClassIntegerGroup> — what we need!<\/p>\n
At least if there is a need to work with the result — it can be used Mono::subscribe<\/strong> to set some AtomicReference field<\/strong> with the result of Mono, instead of Mono::block directly. See example below:<\/p>\n
AtomicReference<MyBestPojoClass> myBestPojoClassHolder = new AtomicReference<>(); pojoClassMono.subscribe(myBestPojoClassHolder::set);<\/code><\/pre>\n\n
It is better not to call blocking operation in general and Mono::block particularly at all when working with Spring Reactor. This example demonstrates how it could lead to deadlock. In this case you can see how Flux::flatMap removes Mono inside of Flux<Mono<PojoClassIntegerGroup>> — and we can work directly with returned type without calling blocking method. If very needed to extract the result of Mono then try Mono::subscribe <\/strong>to set the field as described above in this article. If you have your own recipe of how to avoid call to block in some cases with Reactor — please feel free to write comments here.<\/p>\n
If you have what to say about the topic and want to give negative rating — please feel free to write your comments to understand your opinion. Otherwise it is not serious and it is not clear why you vote negatively.<\/p>\n
And of course If you like this article, please vote UP — this will support me to write more such posts with real code examples!<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/741464\/<\/a>
<\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-421019","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/421019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=421019"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/421019\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=421019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=421019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=421019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}