Fix daemon connection issues #1071
Conversation
|
It seems much less stable on Windows for some reason... |
|
Yep, looks like I'll have to dig into the Windows behavior some more. Taking back into draft. |
oehme
force-pushed
the
mvnd-1.x
branch
3 times, most recently
from
360805c to
96baf69
Compare
|
After a lot of debugging, I've finally figured out the true cause of this, see the updated description. I guess my previous attempt had simply changed the timing slightly, reducing the flakiness on my machine, but increasing it in the Windows builds, which explains those failures. |
Really nice catch. However, even if guava is a transitive dependencies, it's not really a direct dependency in maven. |
The Server was using a SynchrnousQueue to coordinate the main thread and the background thread that receives the request from the client. A SynchronousQueue only allows insertions when a corresponding call to `get` is in progress. However, since the receiver thread is started before the call to `get`, there was a short time window, where the call to `queue.offer` could fail and simply return `false`. This return code was ignored. A possible solution would have been to call `put` instead of `offer`, but I decided to replace the queue with a Future, since we only wait for a single element.
|
Good point, changed to CompletableFuture |
gnodet
added
bug
|
Indeed, great catch @oehme 🙏 |
We have a test suite for a Maven extension that runs around 5000 builds and before this change, on each CI build, about 100 of them would fail with daemon connection issues. The symptom would always be the same - The daemon is waiting for the build request, the client has already sent it, but the daemon never receives it, no matter how long we configured the timeouts.
The reason turned out to be the way that the daemon waits for the request:
The Server was using a SynchrnousQueue to coordinate the main thread
and the background thread that receives the request from the client.
A SynchronousQueue only allows insertions when a corresponding call
to
getis in progress. However, since the receiver thread is startedbefore the call to
get, there was a short time window, where the callto
queue.offercould fail and simply returnfalse. This return codewas ignored.
A possible solution would have been to call
putinstead ofoffer,but I decided to replace the queue with a Future, since we only wait
for a single element.