Не знам дали това ще бъде отговорът на всички, но след известно ровене, ето какво стигнахме.
Грешката очевидно е причинена от факта, че слушателят не приема връзки, но защо да получаваме тази грешка, когато други тестове могат да се свържат добре (можем също да се свържем без проблем чрез sqlplus)? Ключът към проблема не беше, че не можахме да се свържем, а че беше периодично
След известно разследване открихме, че има някои статични данни, създадени по време на настройката на класа, които ще поддържат отворени връзки за целия живот на тестовия клас, създавайки нови, докато върви. Сега, въпреки че всички ресурси бяха правилно освободени, когато този клас излезе извън обхвата (чрез блок finally{}, разбира се), имаше някои случаи по време на изпълнение, когато този клас щеше да погълне всички налични връзки (добре, лошо предупреждение за практика – това беше код за модулен тест, който се свързва директно, а не използва пул, така че същият проблем не може да се случи в производството).
Поправката беше този клас да не се прави статичен и да се изпълнява в настройката на класа, а вместо това да се използва в методите setUp и tearDown по метод.
Така че, ако получите тази грешка в собствените си приложения, пуснете профильор на това лошо момче и вижте дали може да имате изтичане на връзка. Надявам се това да помогне.
