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

[GitBox <gi...@apache.org>]

rpdai 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-541139473
 
 
   How's this going?
   
   I'm very excited about the TCP/IP channel approach, and have been watching for it for much anticipation since the milestone was announced last year. It will be brilliant for us, for maven testing to no longer require stdio to be protected as its communication protocol. We want to inherit stdout/stderr for forked processes under test (ProcessBuilder.inheritIO()) but can't because surefire/failsafe use stdio and complains about corruption when we do it. So we end up discarding console logs for forked applications, making it much harder to solve problems. Effectively, inheritIO is barred from maven based tests right now, even though it is a legitimate JDK feature.
   
   But it seems, there is this impasse about Netty versus pure Java socket use?
   
   My suggestion. Just get it working with pure Java Socket API. Netty is very popular for various reasons. But, really it's not needed in this case. Netty is great when you have to deal with multiple transport mechanisms, non-blocking IO, Unsafe optimisations to direct byte buffers, and other complexities. But if you can stick to blocking I/O, then you already have an elegant socket library built into the JDK. Having Java 7 as your minimum version, already more than you need to make socket and thread handling comfortable. I think there is tendency to want to use Netty as it seems doing anything with the pure JDK seems like reinventing the wheel. But, with just blocking I/O, the wheel is already in the JDK.
   
   Whether blocking I/O is the right choice... you have to go pretty hard at the Socket API before hitting the limit of the typical thread model, and if your'e scaling hard enough to be worrying about such matters, then you have to consider the possibility of clustering your server to scale horizontally! Surely, this sort of consideration isn't applicable to the use case at hand, we're not trying to turn maven into a CI server are we? Rather we're talking about a test framework, using an internal protocol to a small number of clients (relative to e.g. a HTTP server). Blocking I/O can actually be the very efficient approach for such a case. A single thread per client read/write can be fast and easy to reason about.
   
   I wrote a lightweight STOMP client/server with just the Socket API and it was fun to work this way, just a few classes were needed and it performs very well. It's nice sometimes, just to use the JDK to do a job cleanly and elegantly :D
   
   Just a humble opinion. All the work is much appreciated :)

----------------------------------------------------------------
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