Depurar um aplicativo Spring WebFlux pode ser uma tarefa desafiadora, especialmente ao lidar com fluxos reativos complexos. Ao contrário dos aplicativos de bloqueio tradicionais, em que o rastreamento de pilha fornece uma indicação clara da causa raiz de um problema, os aplicativos reativos podem ser mais difíceis de depurar. Problemas como código de bloqueio, problemas de simultaneidade e condições de corrida podem causar bugs sutis difíceis de diagnosticar. Cenário Ao lidar com um bug nem sempre é um problema relacionado ao código. Pode ser um conjunto de fatores, como refatoração recente, mudanças de equipe, prazos rígidos e assim por diante. Na vida real, é comum acabar solucionando grandes aplicativos feitos por pessoas que saíram da empresa há algum tempo e você acabou de entrar. Saber um pouco sobre um domínio e tecnologias não vai facilitar sua vida. No exemplo de código abaixo, eu queria imaginar como seria um código com bugs para uma pessoa que ingressou recentemente em uma equipe. Considere depurar esse código mais como uma jornada do que como um desafio. A causa raiz pode ser óbvia para aqueles que estão familiarizados com aplicativos reativos. No entanto, algumas práticas abaixo ainda podem ser muito úteis para revisar. @GetMapping("/greeting/{firstName}/{lastName}") public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) { return Flux.fromIterable(Arrays.asList(firstName, lastName)) .filter(this::wasWorkingNiceBeforeRefactoring) .transform(this::senselessTransformation) .collect(Collectors.joining()) .map(names -> "Hello, " + names); } private boolean wasWorkingNiceBeforeRefactoring(String aName) { // We don't want to greet with John, sorry return !aName.equals("John"); } private Flux<String> senselessTransformation(Flux<String> flux) { return flux .single() .flux() .subscribeOn(Schedulers.parallel()); } Portanto, o que esse trecho de código faz é: Ele acrescenta “Hello,“ aos nomes fornecidos como parâmetros. Seu colega John está lhe dizendo que tudo funciona em seu laptop. Isso é verdade: > curl localhost:8080/greeting/John/Doe > Hello, Doe Mas quando você o executa como , você vê o próximo stacktrace: curl localhost:8080/greeting/Mick/Jagger java.lang.IndexOutOfBoundsException: Source emitted more than one item at reactor.core.publisher.MonoSingle$SingleSubscriber.onNext(MonoSingle.java:134) ~[reactor-core-3.5.5.jar:3.5.5] Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: Error has been observed at the following site(s): *__checkpoint ⇢ Handler com.example.demo.controller.GreetingController#greeting(String, String) [DispatcherHandler] *__checkpoint ⇢ HTTP GET "/greeting/Mick/Jagger" [ExceptionHandlingWebHandler] Original Stack Trace: <18 internal lines> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java) ~[na:na] (4 internal lines) Bom, nenhum dos rastreamentos leva a um exemplo de código acima. Tudo o que revela é que 1) ocorreu no método e 2) o cliente executou um `HTTP GET "/greeting/Mick/Jagger GreetingController#greeting .doOnError() A primeira e mais fácil coisa a se tentar é adicionar o retorno de chamada `.doOnError()` ao final da cadeia de saudação. @GetMapping("/greeting/{firstName}/{lastName}") public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) { return Flux.fromIterable(Arrays.asList(firstName, lastName)) // <...> .doOnError(e -> logger.error("Error while greeting", e)); } Boa tentativa, mas os logs não mostram nenhuma melhora. No entanto, o rastreamento de pilha interno do Reactor: Aqui estão algumas maneiras pelas quais pode/não pode ser útil durante a depuração: doOnError : você pode usar para registrar mensagens de erro e fornecer mais contexto sobre o que deu errado em seu fluxo reativo. Isso pode ser especialmente útil ao depurar problemas em um fluxo complexo com muitos operadores. Registro doOnError : também pode ser usado para recuperar erros e continuar processando o fluxo. Por exemplo, você pode usar para fornecer um valor ou fluxo de fallback em caso de erro. Recuperação doOnError onErrorResume : provavelmente não fornecerá nenhum stacktrace melhor, exceto o que você já viu nos logs. Não confie nele como um bom solucionador de problemas. Depuração doOnError registro() A próxima parada é substituir a chamada de método adicionada anteriormente pela chamada de método . Por mais simples que pareça. observa todos os sinais de fluxos reativos e os rastreia em logs no nível INFO por padrão. doOnError() log() log() Vamos ver quais informações adicionais vemos nos logs agora: Podemos ver quais métodos Reativos foram chamados ( , e ). Além disso, saber de quais threads (pools) esses métodos foram chamados pode ser uma informação muito útil. No entanto, não é relevante para o nosso caso. onSubscribe request onError Sobre pools de threads O nome do tópico significa . Os métodos reativos e foram executados no pool de threads de E/S (scheduler). Essas tarefas foram executadas imediatamente em um thread que as enviou. ctor-http-nio-2 reactor-http-nio-2 onSubscribe() request() Tendo dentro de , instruímos o Reactor a inscrever outros elementos em outro pool de threads. Essa é a razão pela qual foi executado no thread . .subscribeOn(Schedulers.parallel()) senselessTransformation onError parallel-1 Você pode ler mais sobre pool de threads . neste artigo permite adicionar instruções de log ao seu stream, facilitando o rastreamento do fluxo de dados e o diagnóstico de problemas. Se estivéssemos tendo um fluxo de dados mais complexo com coisas como flatMap, subchains, chamadas de bloqueio, etc., nos beneficiaríamos muito de ter tudo registrado. É uma coisa muito fácil e agradável para o uso diário. No entanto, ainda não sabemos a causa raiz. log() Hooks.onOperatorDebug() A instrução informa ao Reactor para ativar o modo de depuração para todos os operadores em fluxos reativos, permitindo mensagens de erro e rastreamentos de pilha mais detalhados. Hooks.onOperatorDebug() Segundo a documentação oficial: Quando os erros forem observados posteriormente, eles serão enriquecidos com uma Exceção Suprimida detalhando a pilha da linha de montagem original. Deve ser chamado antes que os produtores (por exemplo, Flux.map, Mono.fromCallable) sejam realmente chamados para interceptar as informações corretas da pilha. A instrução deve ser chamada uma vez por tempo de execução. Um dos melhores lugares seria as classes Configuration ou Main. Para o nosso caso de uso seria: public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) { Hooks.onOperatorDebug(); return // <...> } Adicionando podemos finalmente progredir em nossa investigação. Stacktrace é muito mais útil: Hooks.onOperatorDebug() E na linha 42 temos a chamada . single() Não role para cima, o aparece a seguir: senselessTransformation private Flux<String> senselessTransformation(Flux<String> flux) { return flux .single() // line 42 .flux() .subscribeOn(Schedulers.parallel()); } Essa é a causa raiz. emite um item da fonte Flux ou sinaliza para uma fonte com mais de um elemento. Isso significa que o fluxo no método emite mais de 1 item. Subindo na hierarquia de chamadas vemos que originalmente existe um Flux com dois elementos . single() IndexOutOfBoundsException Flux.fromIterable(Arrays.asList(firstName, lastName)) O método de filtragem remove um item de um fluxo quando ele é igual a . Essa é a razão pela qual o código funciona para uma faculdade chamada John. Huh. wasWorkingNiceBeforeRefactoring John pode ser particularmente útil ao depurar fluxos reativos complexos, pois fornece informações mais detalhadas sobre como o fluxo está sendo processado. No entanto, ativar o modo de depuração pode afetar o desempenho do seu aplicativo (devido aos rastreamentos de pilha preenchidos), portanto, ele deve ser usado apenas durante o desenvolvimento e a depuração, e não na produção. Hooks.onOperatorDebug() pontos de verificação Para obter quase o mesmo efeito que oferece com impacto mínimo no desempenho, existe um operador especial. Ele ativará o modo de depuração para essa seção do fluxo, deixando o restante do fluxo inalterado. Hooks.onOperatorDebug() checkpoint() Vamos adicionar dois pontos de verificação após a filtragem e após a transformação: public Mono<String> greeting(@PathVariable String firstName, @PathVariable String lastName) { return Flux.fromIterable(Arrays.asList(firstName, lastName)) .filter(this::wasWorkingNiceBeforeRefactoring) /* new */ .checkpoint("After filtering") .transform(this::senselessTransformation) /* new */ .checkpoint("After transformation") .collect(Collectors.joining()) .map(names -> "Hello, " + names); } Dê uma olhada nos registros: Essa divisão de pontos de verificação nos informa que o erro foi observado após nosso segundo ponto de verificação descrito como . Isso não significa que o primeiro ponto de verificação não foi alcançado durante a execução. Era, mas o erro começou a aparecer só depois do segundo. É por isso que não vemos . Após a transformação Após a filtragem Você também pode ver mais dois pontos de verificação mencionados no detalhamento, de e . Eles foram alcançados após aquele que definimos, até a hierarquia de chamadas. DispatcherHandler ExceptionHandlingWebHandler Além da descrição, você pode forçar o Reactor a gerar um stacktrace para seu ponto de verificação adicionando como segundo parâmetro ao método . É importante observar que o stacktrace gerado o levará à linha com um ponto de verificação. Ele não preencherá um stacktrace para a exceção original. Portanto, não faz muito sentido porque você pode encontrar facilmente um ponto de verificação fornecendo uma descrição. true checkpoint() Conclusão Seguindo essas práticas recomendadas, você pode simplificar o processo de depuração e identificar e resolver problemas rapidamente em seu aplicativo Spring WebFlux. Quer você seja um desenvolvedor experiente ou apenas começando na programação reativa, essas dicas ajudarão você a melhorar a qualidade e a confiabilidade do seu código e oferecer melhores experiências aos seus usuários.
