Une gestion d’erreur de son API .Net automatique via ses exceptions
...
Sommaire
Vous avez diagnostiqué une fuite mémoire et vous voulez corriger le problème.
Si vous utilisez IntelliJ, vous avez à disposition dans votre IDE un outil puissant qui vous permettra de diagnostiquer la source du problème et vérifier votre correction : le profiler.
On va voir à travers un exemple concret comment il peut nous aider.
Je crée une fuite mémoire avec BouncyCastle:
Cipher.getInstance("AES/ECB/PKCS5Padding", new BouncyCastleProvider());
Ici, à chaque appel de mes méthodes “encrypt
” et “decrypt
”, on ajoute une instance de BouncyCastleProvider
qui ne sera jamais clean.
Au bout d’un moment, notre Heap sera pleine et notre serveur va exploser 💥
Dans l’onglet “profiler” vous pouvez ouvrir un fichier hprof
ou jfr
afin d’analyser leur résultat :
Via un flame graph, on isole le responsable
Pour s’en convaincre appelons cette méthode en boucle dans un test unitaire et affichons la consommation mémoire:
@Test void shouldNotOverflow() throws Exception { String password = "M0nSup3rP4ssw0rd"; byte[] encryptedPassword; String decryptedPassword = ""; // Le temps d'ouvrir le profiler Thread.sleep(5000); SecretKey secretKey = getSecretKey(); for (int i = 0; i < 2000; i++) { encryptedPassword = encrypt(password.getBytes(StandardCharsets.UTF_8), secretKey); decryptedPassword = decrypt(encryptedPassword, secretKey); } assertThat(decryptedPassword).isEqualTo(password); }
Faites un clic droit sur le process Junit puis sélectionnez “CPU and Memory Live Charts”
Vous allez voir la Heap monter progressivement jusqu’à saturation:
Vous pouvez aussi cliquer sur l’option “profile” afin d’analyser le processus de test
L’analyse commence:
Ouvrez le rapport généré et sélectionnez « Memory Allocations » en haut à droite.
Sélectionnez l’onglet “Call Tree” à gauche. On voit que le test a eu une allocation de plus de 10 Go !
Editez votre configuration:
En bas, cliquez sur la croix à droite de “Open run/debug tool window when started” puis “ok”.
Cliquez ensuite sur “Modify options”
Une fois qu’on a trouvé le coupable, on va pouvoir investiguer et trouver une solution au problème.
Dans mon cas, ça sera simplement de faire:
Cipher.getInstance("AES/ECB/PKCS5Padding");
Afin d’utiliser toujours le même provider.
Avec les outils qu’on a vu précédemment, il sera très facile de voir si on a résolu le problème sans tester en production.
Dans le profiler, je sélectionne à nouveau “CPU and Memory Live Charts” sur le process Junit:
On a quelques dizaines de Mo de conso mémoire, c’est bien mieux !
Visuellement, on voit bien que la Heap ne monte pas aussi haut qu’avant 😌
J’espère que cet article vous aura permis d’en apprendre un peu plus sur le profiler IntelliJ. Si jamais vous connaissez d’autres fonctionnalités utiles, n’hésitez pas à les mettre en commentaire 🙂
On va voir comment avoir en quelques minutes des assertions qui vont vérifier les endpoints de notre API avec des scénarios de ce genre: Feature: Create a new account As a visitor, I can create an account to access the game Scenario: A visitor c...
Depuis .NET 9, le le support d’OpenAPI est directement inclus dans .NET et ne passe plus par les librairies Swagger par défaut (plus d’info sur ce choix ici si jamais ça vous intéresse). De façons simplifiée, la librairie Swashbuckle.AspNetCore.Sw...
Description du problème Par défaut, il n’est pas autorisé de faire des requêtes entre une application qui est dans un domaine A vers une autre qui serait dans un domaine B (pour des raisons de sécurité, il y a plus de détails dans les sources). S...