Que peut provoquer des erreurs intermittentes ORA-12519 (TNS: aucun gestionnaire approprié trouvé)

Question

Nous exécutons notre suite de tests Junit 4 sur Weblogic 9 devant une base de données Oracle 10 (utilisant Hudson en tant que serveur d'intégration continue) et occasionnellement, nous rencontrons un blocage de ORA-12519 lors du démontage du script. Cependant, l'erreur est très intermittente:

• Cela se produit généralement pour la même classe de test
• Cela ne se produit pas toujours pour les mêmes cas de test (parfois ils réussissent)
• Cela ne se produit pas pour le même nombre de tests (de 3 à 9)
• Parfois, cela ne se produit pas du tout, tout passe

Bien que je ne puisse pas garantir que cela ne se produise pas localement (lorsque vous utilisez la même base de données, bien sûr), j'ai exécuté la même suite de classes plusieurs fois sans problème.

Des idées?

Answer 1

Je ne sais pas si ce sera la réponse de tout le monde, mais après quelques recherches, voici ce que nous avons trouvé.

L'erreur est évidemment causée par le fait que l'auditeur n'acceptait pas les connexions, mais pourquoi aurions-nous cette erreur alors que d'autres tests pourraient se connecter correctement (nous pourrions également ne connecter aucun problème via sqlplus)? La clé du problème n'était pas que nous ne pouvions pas nous connecter, mais que c'était intermittent

Après un examen approfondi, nous avons constaté que certaines données statiques créées lors de l’installation de la classe permettaient de conserver les connexions ouvertes tout au long de la vie de la classe de test et d’en créer de nouvelles au fur et à mesure. Maintenant, même si toutes les ressources ont été correctement libérées lorsque cette classe est sortie de son domaine d'application (via un bloc finally {}, bien sûr), il y a eu des cas pendant lesquels cette classe a englouti toutes les connexions disponibles (ok, mauvais Alerte de pratique: il s’agissait d’un code de test unitaire qui se connectait directement plutôt que d’utiliser un pool, de sorte que le même problème ne puisse pas se produire en production).

Le correctif consistait à ne pas rendre cette classe statique et à l'exécuter dans la configuration de la classe, mais à l'utiliser à la place dans les méthodes set method et tearDown.

Donc, si vous obtenez cette erreur dans vos propres applications, frappez un profileur sur ce mauvais garçon et voyez si vous risquez d'avoir une fuite de connexion. J'espère que ça aide.

Answer 2

Une autre solution que j'ai trouvée à une erreur similaire mais le même message d'erreur consiste à augmenter le nombre de gestionnaires de services trouvés. (Mon instance de cette erreur est due à un trop grand nombre de connexions dans les pools de connexions de portail Weblogic.)

• Exécutez SQL * Plus et connectez-vous en tant que SYSTEM . Vous devez connaître le mot de passe que vous avez utilisé lors de l’installation d’Oracle DB XE.
• Exécutez la commande alter system set tasks = 150 scope = spfile; dans SQL * Plus
• TRÈS IMPORTANT: redémarrez la base de données.

À partir d'ici:

  

http: // www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

Answer 3

J'ai aussi eu le même problème, j'ai cherché les réponses à plusieurs endroits. J'ai eu beaucoup de réponses similaires pour changer le nombre de gestionnaires de processus / services. Mais je me suis demandé si j’avais oublié de le réinitialiser.

J'ai ensuite essayé d'utiliser la méthode Thread.sleep () après chacun de mes connection.close (); .

Je ne sais pas comment, mais ça marche au moins pour moi.

Si quelqu'un veut l'essayer et comprendre comment cela fonctionne, alors n'hésitez pas. J'aimerais aussi le savoir car je suis débutant dans le monde de la programmation.

Answer 4

J'ai eu le même problème. Cela se produisait à chaque fois que j'exécutais un pack de tests de base de données (Spring JDBC) avec SpringJUnit4ClassRunner . J'ai donc résolu le problème en ajoutant @DirtiesContext à chaque test afin de nettoyer le test. contexte d’application et libérer toutes les ressources afin que chaque test puisse s’exécuter avec une nouvelle initialisation du contexte d’application.

Answer 5

J'ai eu ce problème lors d'un test unitaire qui a ouvert de nombreuses connexions à la base de données via un pool de connexions, puis "arrêté". le pool de connexions (ManagedDataSource en fait) pour libérer les connexions à la fin de chaque test. J'ai toujours manqué de connexions à un moment donné dans la suite de tests.

Ajout d'un Thread.sleep (500) dans le démontage () de mes tests et cela a résolu le problème. Je pense que ce qui se passait, c'est que le pool de connexions stop () libère les connexions actives dans un autre thread. Ainsi, si le thread principal continue à exécuter des tests, le ou les threads de nettoyage ont pris tellement de retard que le serveur Oracle n'a plus de connexions. L'ajout du sommeil permet aux threads d'arrière-plan de libérer les connexions en pool.

C’est beaucoup moins un problème dans le monde réel car les serveurs de base de données sont beaucoup plus grands et il existe une combinaison saine d’opérations (pas seulement des opérations sans fin de connexion / déconnexion de base de données).