CODEWITHSUNDEEP
javaspringmultithreadingintellij-ideaspring-webflux
Ilya Y
Ilya Y

Reputation: 854

Possibly blocking call in non-blocking context could lead to thread starvation. Why?

I have such a controller and such a service class. Why am I getting this warning in IDEA - "Possibly blocking call in non-blocking context could lead to thread starvation" ?

enter image description here

@PostMapping(value = {"/create"})
public Mono<ResponseEntity<ResponseDto>> create(
        @RequestBody RequestDto request) {
    ResponseDto result = service.create(request);
    return Mono.just(ResponseEntity.ok(result));
}

@Transactional
public ResponseDto create(RequestDto request) {
    taskRepository.save(request);
    return new ResponseDto("Ок");
}

This is apparently caused by the @Transactional annotation. When I remove it, the warning disappears. What is this problem and how can it be fixed?

p.s. this example is schematic. the real code is bigger.

Upvotes: 6

Views: 17155

Answers (1)

Numichi
Numichi

Reputation: 1092

The reactive process is contrary to the norm. You cannot use blocking elements here! With Tomcat, it creates a separate thread for each request so that the topic can be blocked. Reactive Netty will NOT create a new thread, just uses a fixed pool.

With the loose approach, you can think that if a process is waiting for a response, it gives the resource of that thread to another. If you block it, it won't be able to do that. Therefore, even with a single-threaded Netty, it can handle to serve multiple parallel requests. Therefore, thread-based data storage also does not work properly, because another process can interfere or modify it. Therefore, reactive context is available instead.

There is a article to reactive transaction. I don't know it will be solution for you: https://itnext.io/integrating-hibernate-reactive-with-spring-5427440607fe

Upvotes: 3

Related Questions