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-546744745 I will plan to implement both TCP and UDP, and we can do a performance comparison by running it on real projects' test suites. I am not sure that the difference will be that significant, and if it isn't, supporting both can risk end-user misconfigurations (and in general increase the complexity of the configuration for surefire, which presumably should be avoided if possible). As it looks like you’ve already found out, for small messages that come in bursts, `TCP_NO_DELAY` can provide a significant performacne improvement for TCP connections. I tried to understand what you’ve got here but am having difficulty due to lack of documentation, and because things are not fully connected. Should `ForkedChannelServer` implement `DifferedChannelCommandSender`? If so, why is it in `surefire-extensions-api` and not in `maven-surefire-common`? Do you have any design documentation to point me to? If not, how set are you on this architecture? At a high level, how I would plan to do this is: In `ForkStarter.fork`, we will instantiate some new helper class (called, for instance, `ForkedProcessServer` that will be responsible for creating and managing a `ServerSocket` (or `DatagramSocket` if UDP). This will bind to a random port, then pass that port to the forked process as a parameter. It will be the responsibility of `ForkedProcessServer` to provide the glue between the `ForkClient` the socket? The `ForkProcessServer` will set up `StreamPumper`s similarly to how `CommandLineUtils.executeCommandLine` does right now, but instead of connecting to `stdin` and `stdout`, they will connect to the socket’s streams. I was planning to have a 1:1 mapping of `SocketServer`s to forks, rather than create a single `SocketServer` to keep alive for all forks. It greatly simplifies the implementation and fits better to the existing architecture (which effectively has a dedicated stream for every fork). We already implemented this and did not find significant delays from binding that many `ServerSocket`s, finding that performance still improved dramatically over `stdin`/`stdout` communication (again, see [discussion here](https://github.com/gmu-swe/maven-surefire/pull/2) for a performance breakdown of what we have so far hacked out). How does this all sound to you, @tibor17 (architecturally) and @col-e (in terms of feasibility based on what you’ve already implemented)? I assume that the desired level of configuration is to allow for users to keep on using `stdin`/`stdout` instead of sockets, likely keeping existing behavior by default. The socket setup will be annoying to anyone with an OS that will bring up a GUI warning whenever a process tries to bind to a socket. If it's an eventual goal, then it might also be worthwhile co-designing support for spawning `ForkedBooter`s on separate physical machines and using the socket for communication. I did some work for some clients who used a network file system to replicate the build environment across a cluster of machines. Assuming this is a typical practice, then it may be easy enough to just allow users to specify an IP address to bind to and advertise (or look up whatever `getLocalHostName` resolves to by default), and then also allow users to specify an arbitrary command string to prepend to the `ForkedBooter` process CommandLine (e.g. to specify an `ssh` command, resulting in the command running on a remote machine. Do you have any specific feature requestors who can provide a little more detail on their setups in order to help define the interface for this?
---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
