On Tue, 15 Nov 2022 17:55:17 GMT, Phil Race <[email protected]> wrote:
> Hmm. 5 minutes is a really long time for something that should take less than > 1 second (getting the sequencer). Is that because something else (perhaps > another process) is holding a needed resource ? I tried to find reasons or any kind of patterns by simulating different scenarios like external applications using/holding the audio line, running other sound or midi tests in parallel, switching audio devices during the test execution - and i haven't found a way of stable reproduction or any kind of regularity in test behavior. The only thing i found out is that once test passes the normal way it never fails until system is restarted or wakes up from sleep. The only thing i can say that i had cases when a singular run of the test after the restart demonstrated this problem so it is not a resource locked by another Java instance - there are no other java processes in the system at this point. Which makes me believe that the problem is not on our side and i do not think we can do anything to circumvent the issue on our side. I will continue investigation on the OS side though. > Our CI test harness automatically multiplies test timeout by 2 so you've now > in effect got a VERY long 10 minute timeout on this test .. way too long I > think. Yikes! Yes, 5 minutes is already long enough for this test, multiplying it by two makes it unreasonably long in case when it is properly hangs. I will replace the limit to 120 which makes two minutes timeout on non-multiplied system and somewhat reasonable 4 minutes on CI. ------------- PR: https://git.openjdk.org/jdk/pull/11157
