2 Replies Latest reply on Apr 30, 2018 5:00 PM by vladchuk2

    Difference in behavior between WF10 and 11/12

    vladchuk2

      I have an ear with the configuration web service upon which other components inside the ear depend upon. The config service is deployed first, then other components connect to it at deployment time and get configured

      This used to work fine in WF10, but it seems that it stopped working in 11 and 12 - now config service is not responding, which results in blocked deployment and socket read timeout. It appears that none of the services are available until after all the components in the ear have deployed.

       

      Is this behavior a regression or is it by design? If so, is it documented anywhere?

      Thanks!

        • 1. Re: Difference in behavior between WF10 and 11/12
          vladchuk2

          The problem seems to persist even when the config service is pulled into its own ear and made a dependency for the component in another ear - the config service is blocked until after the timeout occurs in the dependent component (which is in a separate ear).

          Please note that this only manifests itself at the container startup; once started, the components (different ears) can be re-deployed without a problem.

           

          That seems like a regression to me. Comments?

          • 2. Re: Difference in behavior between WF10 and 11/12
            vladchuk2

            Some more revelations. Apparently, the container simply blocks all requests, both internal and external, until after the deployment. This behavior is the result of the new feature introduced in WF11, called "graceful startup". There appears to be no way to revert back to the original, pre-WF11 behavior, and so it became impossible to (cleanly) deploy components in the same container that depend on each other by the way of HTTP requests, whether within a single ear or separate.

             

            Does anyone have any ideas or suggestions? Kind of boring to talk to myself...