Hacker News Reader

Comment by bhauer | Hacker News Reader

Sorry, the links to logs were going to logs from a preview run. I've just changed the links to direct to the final logs. In the final run, play2-scala did not respond:

https://github.com/TechEmpower/TFB-Round-10/blob/master/peak...

View on HN

Generally that error happens when Play tries to bind to a port that's already in use. Looking at the start scripts for the Scala projects, the RUNNING_PID file is just being removed if it exists but your script should probably kill that PID if the file exists before deleting the file.

https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Our suite takes a nuke-from-orbit approach when it comes to killing processes, as this has come up in every round. The idea is that now all tests are run with a specific user, and instead of relying on the test to shut down properly (which MANY could not reliably do), we simply nuke all processes owned by this runner.

It has the downside that if a process forks other processes and drops them into another different user (recently addressed for hhvm, for example), we cannot capture that. However, we have made great strides in trying to avoid that. Additionally, the logging for the application WOULD suggest if a port were bound prior to start-up, and that does not seem to be the case in this example.

Yeah, you should see a java.net.BindException in that case. Play sends it to STDERR rather than STDOUT, I thought maybe that output was being redirected but that doesn't appear to be the case.

The other primary cause of that "oops" message is when evolutions can't be applied but that also doesn't appear to be the case.

Reply on news.ycombinator.com