Community
Participate
Working Groups
Build Identifier: ConnectorTimeoutTests and it's subclasses successful execution depend on some brittle timing constraints. They all have a fixed maxIdleTimeout of 250ms hardcoded and each individual test contains some hardcoded timing information themselves based on that value. Best solution would be to use CountDownlatches, Listeners, etc. to avoid timing issues. If that's not possible or too complicated at least stuff like Thread.sleep(someValue) should have someValue being calculated based on maxIdleTimeout instead of having them hardcoded. Reproducible: Always
Created attachment 209127 [details] proposed patch
applied. but is there more work to do here?
No, can be closed. Refactoring it to make the test execute faster is not worth the work and code clutter it'll require IMHO. Resolving the issue.
Btw. I discussed with Simone that the test might be fragile as it's timing is pretty precise. A GC at the wrong time for example might make the test fail as the timeouts,etc. are pretty small. However if we make them bigger the test will last longer. I suggest to leave it as is and if it fails on hudson, we should review. Do you agree?
