Lors de tests sur une application bancaire mobile, un problème a été identifié : les utilisateurs pouvaient voir leur nombre de tentatives de tirage au sort disponibles, mais en cliquant pour participer, un message indiquait qu'ils ne répondaient pas aux conditions requises. Les journaux d'application et les tests locaux n'ont pas reproduit l'erreur initialement. Après investigation, il a été déterminé que la liste des groupes clients (cifGroupIdList) utilisée pour la vérification des conditions provenait des données de session de l'utilisateur, qui pouvaient être obsolètes.

Processus de diagnostic

Un collègue a suggéré d'utiliser le débogage distant pour résoudre le problème. En connectant l'environnement de développement local à l'instance de test via le débogage JVM, il a été possible d'exécuter le code pas à pas. En plaçant des points d'arrêt dans la méthode de connexion, il a été observé que l'objet utilisateur en cache n'était pas mis à jour après l'ajout dynamique de clients à un groupe. Ainsi, bien que le groupe ait été modifié côté backend, la vérification des conditions utilisait toujours l'ancienne cifGroupIdList stockée dans la session, empêchant la participation.

Cette découverte a mis en évidence un problème de gestion de cache dans le système. La solution a impliqué de forcer une actualisation des données utilisateur lors des opérations critiques ou d'ajouter un mécanisme d'invalidation de cache basé sur les changements de groupe.

Configuration du débogage distant dans IntelliJ IDEA

Pour configurer le débogage distant :

1. Dans IntelliJ IDEA, accédez à "Run/Debug Configurations" et ajoutez une configuration "Remote JVM Debug".
2. Configurez les paramètres : mode "Attach to remote JVM", transport "Socket", hôte avec l'adresse IP du serveur distant (par exemple, 192.168.1.100), et port (comme 6000).
3. Sélectionnez le module de classe local approprié.

Copiez les arguments de ligne de commande générés et ajoutez-les aux options JVM du serveur distant. Exemple de confiugration de démarrage :

JAVA_OPTS="-Xms512m -Xmx512m -Xss256k"
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC -XX:HeapDumpPath=/logs/dump"
JAVA_OPTS="$JAVA_OPTS -Dspring.profiles.active=prod -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=6000"
java -jar $JAVA_OPTS application.jar

Vérifiez que le serveur écoute sur le port spécifié avec la commende :

netstat -tuln | grep 6000

Une fois le serveur redémarré, vous pouvez attacher le débogueur local et reproduire le problème avec l'application mobile pour inspecter le flux d'exécution.