2

I am deploying a WebApplication with several separate war and ear-files to a wildfly 10.1 server.

What I do is this: I clean the deployments, data/content and tmp folder, then copy all necessary war and ear files into the deployments-folder.

Then, I start the Server either in Debug-Mode via Spring Tool Suite 3.8.1 (basically Eclipse Neon) or directly via standalone.sh.

The server starts up normally, gets deploys all projects and publishes this message:

[org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 326001ms - Started 5819 of 6193 services (642 services are lazy, passive or on-demand)

The next message that follows, roughly half a second later, is the first Unregistered web context-message, followed by a general deployment stop. There is no message in the log connected to this, neither an ERROR, nor a WARNING, SEVERE or FATAL in sight.

After stopping all Deployments, the server still runs, but no context is reachable.

When deploying the applications one-by-one, the server accepts, deploys and keeps running, which leads be to believe that there is something wrong with the server itself.

the memory-relevant VM-Arguments are these: -Xms1024m -Xmx4096m. The server does not run on a timeout, as that has been thorougly tested and produces error messages.

Stefan Helmerichs
  • 502
  • 6
  • 19
  • Have you tried to set the logger for `org.jboss.as.server.deployment` to DEBUG? – siom Jan 11 '18 at 09:20
  • I set the ROOT-logger to debug - is the deployment logger covered by this? – Stefan Helmerichs Jan 11 '18 at 09:36
  • No, you need an additional element for `org.jboss.as.server.deployment` set to DEBUG and add the following to the two handlers (file and/or console): – siom Jan 11 '18 at 10:09
  • Thank you, I found that out but did not react until I found something. What I see now it that after the applications were deployed, there is a forced undeploy scan. This seems intentional and normal. `watch -n 0,1` on the deployments directory shows that during deployment, all wars are set to `failed`, but no error appears in the log, and deployment continues. Deployment timeout is set to `600` seconds so that should not be it. – Stefan Helmerichs Jan 11 '18 at 10:18
  • okay, it SEEMS to have stopped now. Why, I don't know. What I found so far is this: `standalone.xml` was set to `deployment-timeout=300` and VM arguments were `-Djboss.as.management.blocking.timeout=600` so I THINK the deployment was set to failed after 300 seconds, but since the blokcing timeout was higher, the application deployed and did not throw error messages. I will keep an eye on this and reply to is if this turns out to be true. – Stefan Helmerichs Jan 11 '18 at 10:41

1 Answers1

3

Okay, long story short: comment was solution.

The parameters deployment-timeout in standalone.xml and jboss.as.management.blocking.timeout as command line parameter do work together on the same thing, considering blocking the command line parameter seemingly has precedence.

So if both values are set, and the management blocker is higher than the deployment-timeout, the following happens:

  • Deployment is started
  • Deployment timeout triggers
  • Management timeout still has time left and does not trigger to stop the server
  • Applications deploy within the management timeout period.
  • The After-Deployment Scanner checks the deployments directory for failures
  • Deloyment-timeout marked all deployments as failures
  • All Deployments are being undeployed as they are faulty

So: No error message, Deployment as usual, followed by instant undeployment. Should anyone else have that, check those values.

Stefan Helmerichs
  • 502
  • 6
  • 19