shark-horse commented on issue #231: Failsafe: Killing self fork JVM. PING timeout elapsed. URL: https://github.com/apache/maven-surefire/pull/231#issuecomment-485870190 The `CommandReader` will delay arbitrarily, just like any other thread, when there are lots of threads and few CPU cores, at least when there is a shortage of RAM and the system is using virtual memory a lot. It is not a thread with boosted priority that the OS is obligated in any way to prioritize over other threads. Also, this is what we observed when I added some hacky logging to a custom surefire build--it would not run for a few minutes. Actually, it might have been that the parent process was paused and did not run for a few minutes--I only logged the times the NOOP was read by `CommandReader`. This leads me to another thought: Although it's possible to guarantee that one task within a process always follows another task (e.g. ensure that we don't check for a ping until CommandReader has read all its input recently), I don't know how to block for another thread _in another process_, directly or indirectly, when what we're doing in the first place is detecting whether the parent process is alive or not. AFAIK we encountered the VM exits only due to severe performance-related problems that we needed to resolve anyway, but I think your upgrades to the code around VM exits is important because it will make it easier to tell a performance issue from e.g. a segmentation fault or a process getting OOM-killed.
---------------------------------------------------------------- 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
