WebFlux Client Hangs indefinitely on Mono.block() #23363
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Is it intentional that this is calling both subscribe and block? Both subscribe, it's just one does it without blocking. |
rstoyanchev
added
the
status: waiting-for-feedback
|
Yes it is intentional. The use case is that there is some synchronous validation that needs to be done by utilizing data in a 4-5 different external services. So these requests are all fired and subscribed to initiate the call asynchronously, once the data is needed down the pipe a aMono.block() is called to return this cached response. Let me know if this is clear. I am doing some additional troubleshooting, it seems when the subscription consumes the error this hanging does not occur. For example: |
spring-projects-issues
added
status: feedback-provided
|
Looks like my last comment stating that if the error is consumed the aMono.block() does not hang is incorrect. It still hangs. Although if I step into the aMono.block() when my debugger is enabled, the thread does not hang.
|
The snippet shown is too basic perhaps, but I still don't understand the reason for caching + subscribing and blocking. If you need to call multiple services and validate when all have returned I would expect that to be composed into a single chain. I have too little information to work with but based on the given description it could be something like this: Mono<A> aMono = webClient.get().uri().retrieve().bodyToMono(A.class);
Mono<B> bMono = webClient.get().uri().retrieve().bodyToMono(B.class);
Mono<C> cMono = webClient.get().uri().retrieve().bodyToMono(C.class);
Mono<D> dMono = webClient.get().uri().retrieve().bodyToMono(D.class);
Mono.zip(aMono, bMono, cMono, dMono)
.doOnNext((a,b,c,d) -> {
// ...
)}
.block(); |
rstoyanchev
added
status: waiting-for-feedback
|
Thanks @rstoyanchev for the reply. Let me expand a little bit on the current use case and the limitations with your suggestion. Instead, with my current solution I am able to Again, the thread only hangs, if actuator module is enabled AND one of the responses returns an error. If i remove the actuator module OR all responses return without error, the mono.block() does not hang. I have yet to test if this occurs with a Flux.block() under these sames conditions. |
spring-projects-issues
added
status: feedback-provided
It doesn't max out. Please check the variant that takes Iterable.
It's not an implementation of anything. It's a sketch based on a very incomplete description.
All of this sounds quite feasible with 1) and 2) modeled as independent streams to be joined when complete, and 1) itself consisting of 5 more sub-streams joined with zip. I ask you to change your assumption this can only be done with cache, async, and block, but this is now turning into a discussion better suited for StackOverflow. I'm afraid there isn't anything I can do without a sample that demonstrates the issue. I can't tell you why it blocks based on a loose description of a complex scenario. In addition, if Actuator is the cause of anything that can't be fixed here in the Spring Framework. |
rstoyanchev
added
status: invalid
|
@rstoyanchev |
|
Okay, if you get that feel free to comment here for consideration. |
|
I never circled back around but I was able to get this to work by registering an error consumer. Without registering this consumer, it seems if the first subscription (aMono.subscribe()) generates an error, the error is not "cached" and replayed to the second subscription aMono.block() leaving the second subscription hanging waiting for a signal which of course never occurs. Not sure if this expected behavior, but posting this incase anyone else has a similar use case. Mono aMono = webClient.get().uri().retrieve().bodyToMono(A.class).cache() |
Versions:
org.springframework.boot:spring-boot-starter:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-actuator:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-data-mongodb:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-data-jpa:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-log4j2:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-web:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-webflux:2.1.1.RELEASE
org.springframework.boot:spring-boot-starter-test:2.1.1.RELEASE
org.springframework.cloud:spring-cloud-starter-sleuth:2.1.1.RELEASE
org.springframework.security:spring-security-test:5.1.2.RELEASE
So I am having a very strange issue where Mono.block() hangs indefinitely and it only seems to occur when spring-boot-start-actuator is included as a dependency and the service being called returns an error status. Not sure what the relation is or if I am doing something wrong.
Below is the code being used:
Mono<A> aMono = webClient.get().uri().retrieve().bodyToMono(A.class).cache()aMono.subscribe()aMono.block()If if the service returns a successful response, the aMono.block() returns without issue.
If spring-boot-starter-actuator:2.1.1.RELEASE dependency is removed, aMono.block() returns without issues for successful and errors responses.
Below is where the thread hangs:
The text was updated successfully, but these errors were encountered: