Recientemente me he hecho cargo del mantenimiento de un Spring Boot proyecto. Este proyecto tiene algunas Límite de tarifa errores en los registros cuando la aplicación se ponía en contacto con una API REST remota. Resulta que esta aplicación también utilizaba el método síncrono y bloqueante Plantilla RestTemplate para realizar las llamadas a la API, en lugar del más reciente Spring WebClientque resulta que utiliza la API Reactor bajo el capó.
¿Y sabes qué es lo mejor de Reactor y del uso de APIs Reactivas en general? Hace que programar con Data Stream sea muy fácil. Lo que también significa que facilita la implementación de estrategias de reintento.
Hablemos primero del error en el registro. Lo que obtuve se parecía a esto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
org.springframework.web.client.HttpClientErrorException$TooManyRequests: 429 Too Many Requests: [{"response_type":"ERROR","message":"Number of requests has exceeded the 1 minute limit"}] at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:137) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:184) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:125) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:782) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:740) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:674) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:315) ~[spring-web-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at com.couchbase.training.couchlms.repository.LmsRepository.getCourseModules(LmsRepository.java:102) ~[classes!/:0.0.40-SNAPSHOT] at com.couchbase.training.couchlms.services.LmsProcessor.processCourseModules(LmsProcessor.java:147) [classes!/:0.0.40-SNAPSHOT] at com.couchbase.training.couchlms.services.LmsProcessor.processCourses(LmsProcessor.java:91) [classes!/:0.0.40-SNAPSHOT] at com.couchbase.training.couchlms.config.SchedulingConfig.scheduledCoursesPuller(SchedulingConfig.java:45) [classes!/:0.0.40-SNAPSHOT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_252] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_252] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_252] at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_252] at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:84) [spring-context-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54) [spring-context-5.2.9.RELEASE.jar!/:5.2.9.RELEASE] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_252] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_252] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_252] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_252] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_252] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_252] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_252] |
Como de costumbre, la parte interesante de las trazas de pila está en la parte superior. El error es 429 Demasiadas solicitudesy el mensaje dice que hay un Límite de velocidad de 1 minuto. Descomponiendo esto, el estado HTTP el código devuelto es 429. Se trata de un error de límite de velocidad, lo que significa que la API indica a la persona que llama que ha enviado demasiadas peticiones. Por lo general, esto se puede resolver esperando un poco, e incluso podría tener un Reintentar después de en la respuesta que le indica cuánto tiempo tiene que esperar.
Veamos cómo podemos obtener esa información con WebClient de Spring:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
.uri(ub -> ub.pathSegment(uri).queryParams(queryParams).build()) .retrieve() .onStatus( HttpStatus.TOO_MANY_REQUESTS::equals, response -> { List<String> header = response.headers().header("Retry-After"); Integer delayInSeconds; if (!header.isEmpty()) { delayInSeconds = Integer.valueOf(header.get(0)); } else { delayInSeconds = 60; } return response.bodyToMono(String.class).map(msg -> new RateLimitException(msg, delayInSeconds)); }) .bodyToMono(String.class) |
Este código está enviando un GET petición. El WebClient nos permite echar un vistazo a la respuesta de la petición y reaccionar adecuadamente gracias a la función onStatus método. El primer parámetro es un booleano utilizado para filtrar el código de estado HTTP devuelto. Aquí, cuando el código de estado es 429, hacemos algo.
Echamos un vistazo a la Respuesta mirar si hay un Reintentar después de si es así, inicializamos la cabecera delayInSeconds si no, establecemos un valor por defecto de 60. Entonces podemos devolver el Respuesta asignado a un RateLimitException. El contenido del cuerpo se utilizará como mensaje de error y el delayInSeconds estará disponible en un campo separado. Echa un vistazo al código de Excepción para más detalles:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
import java.time.Duration; public class RateLimitException extends Throwable { private int retryAfterDelay = 60; public RateLimitException(String message) { super(message); } public RateLimitException(String message, int retryAfterDelay) { super(message); this.retryAfterDelay = retryAfterDelay; } public int getRetryAfterDelay() { return retryAfterDelay; } public Duration getRetryAfterDelayDuration() { return Duration.ofSeconds(retryAfterDelay); } } |
Así que lo que hay que hacer es capturar este error específico y luego volver a intentarlo después de la duración dada. Reactor lo hace fácil proporcionando Reintentos estrategias. Todo lo que tiene que hacer es llamar al reintentarCuando método:
|
1 2 3 4 5 6 |
.bodyToMono(String.class) .retryWhen(Retry.withThrowable(throwableFlux -> { return throwableFlux.filter(t -> t instanceof RateLimitException).map(t -> { RateLimitException rle = (RateLimitException) t; return Retry.fixedDelay(1, rle.getRetryAfterDelayDuration()); }); |
Existen diferentes Reintentar podemos utilizar el método withThrowable() constructor. Da un Flux que debe contener el RateLimitException. Así que empezamos aplicando un filtro para asegurarnos de ello. Luego mapeamos esa excepción al objeto Retry real. Aquí es el Retry.fixedDelay tomando como parámetros un máximo de intentos y una duración. La duración procede del RateLimitException que se lanzó antes.
Con eso, cada vez que una petición devuelva un 429, el cliente esperará el tiempo apropiado hasta que reintente. Y fue mucho más fácil de implementar con Reactor que usando try/catch con Spring's Plantilla RestTemplate. Sé que la programación reactiva puede ser un poco intimidante al principio, pero es una gran manera de gestionar flujos de datos como solicitudes y respuestas HTTP, o para gestionar las conexiones a bases de datos que soportan la programación reactiva, como Couchbase.
¿Quieres más ayuda e ideas?
