You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2019/10/24 08:04:56 UTC

[GitHub] [maven-surefire] jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.

jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545798173
 
 
   Hi @Tibor17 and @rpdai,
   I have great interest in this feature too, and we have hacked out a proof-of-concept to use sockets to communicate between the two JVMs, and observed significant speedups when running tests with `reuseForks=false`. @Col-E and I did some very detailed profiling of the latency between `ForkStarter` and `ForkedBooter` and found that most of the delay was coming on *shutdown* thanks to the JVM's enforced blocking timeout when reading from `stdin`. This in-depth response to a StackOverflow post ["Blocking on stdin makes Java processes take 350ms or more to exit"](https://stackoverflow.com/a/48979347/) explains the issue in great detail. We confirmed with @gliga (who was the researcher at UT Austin who reported [Surefire-1516](https://issues.apache.org/jira/browse/SUREFIRE-1516)) that switching from stdin/stdout to sockets effectively removes the startup/teardown latency that they observed as well.
   
   When we implemented this, we felt uncomfortable asking you to merge these changes in because we realized that there would need to be some invasive changes to throughout `maven-surefire-common`. However, now that we see this PR and branch, it looks like thankfully, you have already implemented some re-architecting to allow us to more easily change from using stdin/stdout to sockets. I would be very happy to take [our fast, Java socket-based implementation](https://github.com/gmu-swe/maven-surefire/pull/2) and refactor it to use the abstractions that you've created here for managing the communication, and re-apply those changes to `maven2surefire-jvm-communication`. However, your branch `maven2surefire-jvm-communication` is currently not compiling correctly, and I am not sure what the most appropriate fix will be. Please let me know if this would be a useful contribution, and if so, how to proceed based on the broken status of this branch.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services