¿Cómo convertir un Mono en una llamada de método verdaderamente asíncrona (¡no reactiva!)?
Tengo un método
java-lang
@Service
public class MyService {
public Mono<Integer> processData() {
… // operación reactiva muy larga
}
}
En el flujo normal del programa, llamo a este método de forma asíncrona a través de un evento de Kafka.
Para fines de prueba, necesito exponer el método como un servicio web, pero el método debe ser expuesto como asíncrono: devolviendo solo el código HTTP 200 OK (“solicitud aceptada”) y continuando el procesamiento de datos en segundo plano.
¿Está bien (= no tiene efectos secundarios no deseados) simplemente llamar a Mono#subscribe() y regresar desde el método del controlador?
@RestController
@RequiredArgsConstructor
public class MyController {
private final MyService service;
@GetMapping
public void processData() {
service.processData()
.subscribeOn(Schedulers.boundedElastic())
.subscribe();
}
}
¿O es mejor hacerlo así (aquí estoy confundido por la advertencia de IntelliJ, tal vez la misma que https://youtrack.jetbrains.com/issue/IDEA-276018?):
lang-java
public Mono<Void> processData() {
service.processData()
.subscribeOn(Schedulers.boundedElastic())
.subscribe(); // IntelliJ se queja de “llamada inapropiada a 'subscribe'”, pero creo que es una falsa alarma en mi caso(?)
return Mono.empty();
}
¿O alguna otra solución?
davy.ai
Como experto en IT especializado en Java, asíncrono, Spring-Webflux y Project-reactor, recomendaría el segundo enfoque.
En el primer enfoque, llamar a
Mono#subscribe()y volver del método del controlador puede no causar efectos secundarios no deseados, pero no es una práctica recomendada. No proporciona ninguna señal al cliente de que se ha aceptado la solicitud, lo que puede causar confusión.El segundo enfoque es más apropiado ya que devuelve un
Mono<void>que se completa inmediatamente con un código de estado HTTP 200, señalando al cliente que se ha aceptado la solicitud. Además, el métodosubscribe()se llama dentro del métodoprocessData(), lo que crea una cadena para toda la computación asíncrona.Con respecto a la advertencia de IntelliJ, puede ser una falsa alarma si el método
processData()es el único responsable del procesamiento asíncrono de los datos. Sin embargo, si es posible, es mejor proporcionar una devolución de llamada asubscribe(), que maneje las señales de error y finalización, para evitar posibles problemas en el futuro.En general, el segundo enfoque es la forma correcta de exponer el método como un servicio web asíncrono.