Nie wiem, czy to będzie odpowiedź wszystkich, ale po kilku poszukiwaniach oto, co wymyśliliśmy.
Błąd jest oczywiście spowodowany tym, że słuchacz nie akceptował połączeń, ale dlaczego mielibyśmy otrzymać ten błąd, gdy inne testy mogły się połączyć dobrze (możemy też bez problemu połączyć się przez sqlplus)? Kluczem do problemu nie było to, że nie mogliśmy się połączyć, ale że było to sporadyczne
Po pewnym badaniu odkryliśmy, że podczas konfigurowania klasy powstały pewne statyczne dane, które utrzymywały otwarte połączenia przez cały okres istnienia klasy testowej, tworząc nowe w miarę postępu. Teraz, mimo że wszystkie zasoby zostały prawidłowo zwolnione, gdy ta klasa wyszła poza zakres (oczywiście przez blok finish{}), zdarzały się przypadki podczas uruchamiania, w których ta klasa połknęła wszystkie dostępne połączenia (w porządku, źle ostrzeżenie o praktyce - był to kod testu jednostkowego, który był połączony bezpośrednio, a nie za pomocą puli, więc ten sam problem nie mógł wystąpić w środowisku produkcyjnym).
Poprawka polegała na tym, aby ta klasa nie była statyczna i działała w konfiguracji klasy, ale zamiast tego używała jej w metodach setUp i tearDown dla poszczególnych metod.
Jeśli więc pojawi się ten błąd we własnych aplikacjach, wrzuć profiler do tego złego chłopca i sprawdź, czy nie ma wycieku połączenia. Mam nadzieję, że to pomoże.
