Closed rollodp closed 12 years ago
Moved to JIRA https://issues.jboss.org/browse/JBASMP-30
Still seems to be an issue in 7.3-Final. The code is:
while (server.isRunning()) {
TimeUnit.SECONDS.sleep(1L);
}
which will surely loop forever if the server has started before reaching this point. Shouldn't this be:
while (!server.isRunning()) {
TimeUnit.SECONDS.sleep(1L);
}
It has to loop forever. If it doesn't maven would continue the build and the process would be destroyed. I did test running for about 30-45 minutes and my CPU sat at 0% usage.
Ok, I thought that the run goal would not block, instead return control to maven once the server is started. If it is supposed to block then how should JBoss be shut down so that Maven would continue?
BTW, StandaloneServer.isRunning() will return false if the server state is STARTING so the loop would exit rather than block if JBoss doesn't start almost immediately:
final ModelNode result = client.execute(Operations.createReadAttributeOperation(Operations.SERVER_STATE));
isRunning = Operations.successful(result) &&
!STARTING.equals(Operations.readResultAsString(result)) &&
!STOPPING.equals(Operations.readResultAsString(result));
The scenario we are looking to support is:
For this to work we would need the Run goal to fork JBoss once it's started rather than block. If it is supposed to block by design then can a configuration option be added to support forking?
<fork>true</fork>
Thank for the detailed information. I've added the comments to https://issues.jboss.org/browse/JBASMP-25.
One note is the server.start() blocks, with a timeout, until the server is actually started. So the StandaloneServer.isRunning() will only return false if the timeout is reached of the server fails to start.
The run goal should return when the server has started but intermittently hangs with 100% CPU. I believe the cause to be flawed logic in the loop that checks for server startup.
In Run.java:200 (7.2-FINAL), what is currently:
i.e. if the server reaches a running state before this loop is reached then loop indefinitely
It should instead be something like:
For extra safety it should probably also respect the startup-timeout parameter.