RC3: tradebeans and tradesoap non-adjustable server port number
farquet opened this issue · comments
Trying to run tradebeans or tradesoap on a machine that already uses port 8080 causes the benchmark to end prematurely without error message but with a non-zero exit code.
This is due to jboss/wildfly which listens by default on port 8080.
This is confirmed by this line in scratch/log/server.log:
WFLYCTL0186: Services which failed to start: service org.wildfly.undertow.listener.default: Address already in use /127.0.0.1:8080
However, even though an error message to point out the problem would be nice to have, there is currently no workaround to make the benchmarks run in such an environment.
Specifying -Djboss.http.port=8084 makes the benchmark fail (also without error message) despite scratch/log/server.log looking sane. I suspect this is due to the hardcoded port number in DacapoClientRunner
Thanks for that. I will investigate.
I've addressed this in 91d6663.
This commit checks whether the port is in use and exits with a clear explanation if so.
In principle it also allows the port to be changed. However, after some investigation I was unable to get port changes to work. The many hard coded 8080's in the daytrader and wildfly code base appear not to be the problem (changing them to 8081 had no effect on the problem). The server appeared to correctly come up respecting the port changes and the client correctly looked to the new port (eg 8180), however the daytrader service never appeared at that port.
I have exhausted my capacity to address the underlying Wildfly issue, but at least for now we have clean behavior instead of the system dying silently.
This is one of those behaviors we would have to address if we want to run dacapo in a "cloud-native" fashion with multiple JVMs. That is, regardless of what else is running on the system (even if it is clean), multiple instances of dacapo-tradebeans cannot be running at the same time because they all will ask for port 8080. The first one will get it and the others will shut down.
I've fixed the issue now.
The problem I had overlooked was that jboss.http.port and jboss.socket.binding.port-offset are summative, not independent. So if the port is specified as 8090 and the offset is specified as 100, then port 8190 is the port that will be used.
So the code now allows both of these to be independently applied (the former specifies the http port, the later an offset on all ports used by Wildfly.
The code also looks for a port conflict on the default http port and finds the next available port if necessary. I've only done minimal testing of this automatic port reassignment (it's not trivial).
Unless something else comes up, I'm closing this for RC4.
Following-up on this, I've tested tradebeans on RC4. port-offsetting seems to work properly, so at least a workaround exists. Thanks for this!
However, it seems that automatic port selection is a bit fragile. Indeed, if something is already running on port 8080, the benchmark sends some requests to it.
A good way to test this is to start an HTTP server on this port while running the benchmark in another shell:
$ python3 -m http.server 8080
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...
127.0.0.1 - - [12/Oct/2023 14:01:18] code 404, message File not found
127.0.0.1 - - [12/Oct/2023 14:01:18] "GET /daytrader HTTP/1.1" 404 -
127.0.0.1 - - [12/Oct/2023 14:01:18] code 404, message File not found
127.0.0.1 - - [12/Oct/2023 14:01:18] "GET /daytrader HTTP/1.1" 404 -
127.0.0.1 - - [12/Oct/2023 14:01:18] code 404, message File not found
127.0.0.1 - - [12/Oct/2023 14:01:18] "GET /daytrader HTTP/1.1" 404 -
127.0.0.1 - - [12/Oct/2023 14:01:18] code 404, message File not found
127.0.0.1 - - [12/Oct/2023 14:01:18] "GET /daytrader HTTP/1.1" 404 -
127.0.0.1 - - [12/Oct/2023 14:01:18] code 404, message File not found
127.0.0.1 - - [12/Oct/2023 14:01:18] "GET /daytrader HTTP/1.1" 404 -
127.0.0.1 - - [12/Oct/2023 14:01:18] code 404, message File not found
...
An undesired consequence of this could be that if a daytrader process is already running, the benchmark will happily run against it instead of the one it's supposed to launch.