Non so se questa sarà la risposta di tutti, ma dopo aver scavato un po', ecco cosa ci è venuto in mente.
L'errore è ovviamente causato dal fatto che l'ascoltatore non stava accettando le connessioni, ma perché dovremmo ricevere quell'errore quando altri test potrebbero connettersi correttamente (potremmo anche connetterci senza problemi tramite sqlplus)? La chiave del problema non era che non potevamo connetterci, ma che era intermittente
Dopo alcune indagini, abbiamo scoperto che durante l'impostazione della classe erano stati creati alcuni dati statici che avrebbero mantenuto le connessioni aperte per tutta la vita della classe di test, creandone di nuove man mano che procedeva. Ora, anche se tutte le risorse sono state rilasciate correttamente quando questa classe è uscita dall'ambito (tramite un bloccofinal{}, ovviamente), ci sono stati alcuni casi durante l'esecuzione in cui questa classe avrebbe inghiottito tutte le connessioni disponibili (ok, male avviso di pratica:si trattava di un codice di unit test che si collegava direttamente anziché utilizzare un pool, quindi lo stesso problema non poteva verificarsi in produzione).
La soluzione consisteva nel non rendere quella classe statica ed eseguirla nell'impostazione della classe, ma usarla invece nei metodi per method setUp e tearDown.
Quindi, se ricevi questo errore nelle tue app, schiaffeggia un profiler su quel ragazzaccio e vedi se potresti avere una perdita di connessione. Spero di esserti stato d'aiuto.
