Optimisation du code

J'ai réalisé d'un travail d'optimisation des services.

• en éxecutant le service en asynchrone (Executors.newVirtualThreadPerTaskExecutor() ou Executors.newVirtualThreadPerTaskExecutor() ou Executors.newSingleThreadExecutor() ou Executors.newThreadPerTaskExecutor(Thread.ofVirtual().factory()))
• en parallélisant les tâches, par exemple pour construire un zip, dans la mesure du possible créer plusieurs fichiers en même temps pour le remplir.
• En utilisant Flux reactive kà où c'est possible ce qui évite la fermeture de la requête.

Tu peux déjà pousser ce travail sur dev voire sur preprod pour l'éprouver.

J'aimerai aussi que tu vérifies la bonne utilisation des ces composants que je ne manipule pas forcement dans l'esprit de l'art. En particulier, utilise-e le bon mécanisme de threading; est ce que la limite des connexions à la base ne risque pas de rendre des thread bloquants. Est ce que je conserve la gestion des erreurs (encapsulation des erreurs dans un ExecutionException non traité par jackson via les errorsHandlers

Je pense que tu est plus calé que moi dans l'usage de ces outils et surtout leur limite.

En première instance, il semble que les services soient drastiquement accélérés. Mais on pourrait imaginer que ces performances chutent dans certains cas.

Pour exemple dans la récupération de la base depuis le bundle-zip, j'ai imaginé une stratégie ou l'on prenait des lots de référentiels à déposer en parallèle. On sait qu'il peut y avoir des dépendances entre ces référentiels ce qui généèrerait des erreurs si l'ordre n'est pas respecté. Je suis parti du principe que dans un lot, tous les référentiels présents n'avaient pas de références ou leur référence étaient soit dans le lot soit déjà déposées. En bloquant les référentiels pour lesquels il manque des dépendances, je m'assure de ne pas avoir un lot complètement bloqué. Voici un exemple de parallélisme bloquant s'il est mal traité.

Le travail est dans develop f14bf8f6