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'écouteur n'acceptait pas les connexions, mais pourquoi obtiendrions-nous cette erreur alors que d'autres tests pourraient se connecter correctement (nous pourrions également nous connecter sans 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 quelques recherches, nous avons découvert qu'il y avait des données statiques créées lors de la configuration de la classe qui garderaient les connexions ouvertes pendant toute la durée de vie de la classe de test, en créant 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 la portée (via un bloc finally {}, bien sûr), il y a eu des cas pendant l'exécution où cette classe engloutissait toutes les connexions disponibles (d'accord, mauvais alerte de pratique - il s'agissait d'un code de test unitaire qui se connectait directement plutôt que d'utiliser un pool, donc le même problème ne pouvait pas se produire en production).
Le correctif consistait à ne pas rendre cette classe statique et à s'exécuter dans la configuration de la classe, mais à la place de l'utiliser dans les méthodes setUp et tearDown par méthode.
Donc, si vous obtenez cette erreur dans vos propres applications, giflez un profileur sur ce mauvais garçon et voyez si vous pourriez avoir une fuite de connexion. J'espère que ça aide.
