2 votes

Axon Framework Implémentation de l'IntervalRetryScheduler uniquement pour certaines commandes

J'ai une Saga et la Saga envoie des commandes à différents microservices sur des événements spécifiques. Certains microservices peuvent être en panne plus que d'autres, je veux donc configurer une CommandGateway avec un RetryScheduler et aussi implémenter mon propre IntervalRetryScheduler de sorte que je puisse faire un retry pour chaque RuntimeException mais seulement pour certaines Commandes Axon (ceci a été d'une grande aide). Pourquoi le RetryScheduler d'Axon Framework ne réessaie-t-il pas après une NoHandlerForCommandException ? ).

Tout fonctionne comme prévu, ma seule préoccupation est de savoir s'il y a des problèmes dus au fait que certaines commandes seront envoyées avec la CommandGateway par défaut et d'autres avec ma CommandGateway personnalisée qui a le retry personnalisé intégré ?

Pour l'instant, je n'utiliserais pas la passerelle de commande personnalisée, même pour les commandes sans essai.

J'ai opté pour l'approche distincte des haricots CommandGateway

    @Bean
    public CommandGateway commandGateway(){
        Configurer configurer = DefaultConfigurer.defaultConfiguration();
        CommandBus commandBus = configurer.buildConfiguration().commandBus();
        CommandGateway commandGateway = DefaultCommandGateway.builder().commandBus(commandBus).build();
        return commandGateway;
    }

    @Bean
    public CommandGateway commandGatewayWithRetry(){
        Configurer configurer = DefaultConfigurer.defaultConfiguration();
        CommandBus commandBus = configurer.buildConfiguration().commandBus();
        ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
        RetryScheduler rs = IntervalRetrySchedulerImpl.builder().retryExecutor(scheduledExecutorService).maxRetryCount(5).retryInterval(1000).build();
        CommandGateway commandGateway = DefaultCommandGateway.builder().commandBus(commandBus).retryScheduler(rs).build();
        return commandGateway;
    }

2voto

Steven Points 2089

À partir de maintenant, vous pouvez adopter plusieurs angles d'attaque.

Si vous avez l'intention d'utiliser le RetryScheduler / CommandGateway vous pouvez faire l'une ou l'autre des choses suivantes.

  • Configurer des fonctions distinctes CommandGateway les haricots, avec ou sans le RetryScheduler
  • Soyez précis quant au type d'exception levée par les sagas pour les tentatives, de sorte que vos RetryScheduler peut être adapté de manière à ce que la réessai se fasse oui ou non.
  • Construire une passerelle de commande personnalisée (comme décrit aquí ). À partir de là, vous pouvez être aussi précis que vous le souhaitez en ce qui concerne le comportement de certaines commandes.

Cependant, je pense que la solution proposée dans ce Groupe d'utilisateurs Axon serait plus intéressant à suivre dans votre situation. Pour résumer l'approche proposée, l'idée est de planifier le retry dans la Saga elle-même en utilisant la fonction Date limite mécanisme fourni par Axon.

De cette façon, vous pouvez laisser la commande échouer si le microservice est indisponible (ce qui, je suppose, est le problème que vous essayez de résoudre) et faire en sorte que la Saga elle-même réessaie l'opération après un certain délai.

J'espère que cela vous aidera !

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X