3 Replies Latest reply on Nov 20, 2019 2:45 AM by lokeshwar123

    WFLYSRV0220 shutdown requested when web context is polled after it's registered but before the EAR finishes initializing

    jasipher
    jasipher Jul 12, 2017 8:20 PM

      I have an EAR file containing several WAR files. A separate process is polling one of the web apps every 10-20 seconds. If I start WildFly before the polling process starts everything works fine, but if the polling process is running while WildFly starts WildFly logs "INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested via an OS signal" the first time it's polled after the web context is registered for the web app that responds to the poll.

       

      The log always looks like this when it fails. /myapp/util is the context for the web app that responds to the polls. The classes referenced in the next two messages are part of another web app in the same EAR.

       

      17:22:48,004 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 93) WFLYUT0021: Registered web context: /myapp/util

      17:22:48,127 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 89) RESTEASY002225: Deploying javax.ws.rs.core.Application: class com.bla.bla.SomeRESTEasyApp

      17:22:48,128 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 89) RESTEASY002200: Adding class resource com.bla.bla.SomeClass from Application class com.bla.bla.SomeRESTEasyApp

      17:22:48,339 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested via an OS signal

       

      Any suggestions on ways to fix it will be appreciated. We're using WildFly-10.1.0.Final. If there's some way to force WildFly to register that web context last it might do the trick, but Google hasn't helped me with that.

        • 1. Re: WFLYSRV0220 shutdown requested when web context is polled after it's registered but before the EAR finishes initializing
          jaikiran
          jaikiran Jul 13, 2017 3:59 AM (in response to jasipher)

          Looking at the code which emits this log message, I'm guessing that some part of the code path within your application which deals with that polling request handling is issuing a System.exit() call which results in the JVM exiting. Have you looked for such calls within the application? If there are any such calls, you will have to remove those.

            • Actions
          • 2. Re: WFLYSRV0220 shutdown requested when web context is polled after it's registered but before the EAR finishes initializing
            jasipher
            jasipher Jul 13, 2017 11:25 AM (in response to jaikiran)

            Thanks Jaikiran, that got me on the right path.

              • Actions
            • 3. Re: WFLYSRV0220 shutdown requested when web context is polled after it's registered but before the EAR finishes initializing
              lokeshwar123
              lokeshwar123 Nov 20, 2019 2:45 AM (in response to jasipher)

              Hello jaikiran ,

              Currently we are facing same issue .

              2019-11-20 07:17:39,403 INFO  [stdout] (default task-53) 2019-11-20 07:17:39.403 [356] FINE  interceptors.RequestCycleAuthInterceptor - DOCREQ002 : AppId: [CIS2] - Env: [PROD] -  Time Taken to filter results: 6

              2019-11-20 07:17:39,828 INFO  [org.jboss.as.server] (Thread-3) WFLYSRV0220: Server shutdown has been requested via an OS signal

              2019-11-20 07:17:40,322 INFO  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 92) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory

              2019-11-20 07:17:40,399 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 105) WFLYUT0022: Unregistered web context: '/cisweb' from server 'default-server'

              2019-11-20 07:17:40,401 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 154) WFLYUT0022: Unregistered web context: '/generator-seta' from server 'default-server'

              As u said
              ++++++++++
              Looking at the code which emits this log message, I'm guessing that some part of the code path within your application which deals with that polling request handling is issuing a System.exit() call which results in the JVM exiting. Have you looked for such calls within the application? If there are any such calls, you will have to remove those.
              +++++++

              we have checked with our application team and they are not  having this type of calls .
              Do you any alternative option to resolve this issue ..?? Please respond ASAP .







                • Actions