Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-4510

remoting cannot start without default worker and does not work with non-default worker for http-upgrade

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Critical
    • 9.0.1.Final
    • 8.0.0.Final, 9.0.0.Final
    • Remoting
    • None
    • Hide

      The example standalone-full demonstrates remoting failing to start without the default worker defined but the broader issue is that http-upgrade does not work when the http-listener is using a different worker because remoting appears to keep using the default worker
      ./bin/standalone.sh -c standalone-full.noDefault.xml

      Show
      The example standalone-full demonstrates remoting failing to start without the default worker defined but the broader issue is that http-upgrade does not work when the http-listener is using a different worker because remoting appears to keep using the default worker ./bin/standalone.sh -c standalone-full.noDefault.xml

    Description

      Originally we could not get remote+http to work with a non-default worker after following all the changes we found in the schema. It looks like remoting uses the default worker even when the endpoint is configured to use a different worker.

      Attachments

        Issue Links

          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-16876 remoting cannot start without default worker and does not work with non-default worker for http-upgrade

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Activity

            People

              bstansbe@redhat.com Brian Stansberry
              wreicher1@redhat.com Will Reichert
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: