You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 20, 2019. It is now read-only.
Right now all the tests run with Kestrel. When I briefly tried WebListener some of the test cases failed. The logs showed WebListener starting fine, but it never served any requests and HttpPlatformHandler kept re-starting the back-end process until it gave up.
I've seen it work when published to full IIS, so it might be a test setup issue.
Ok, now we understand why it doesn't work, and it won't any time soon.
HttpPlatformHandler starts the back-end process (dnx.exe). Then it opens a socket and tries to connect to the specified port. When that succeeds it cross checks the process that opened the port with it's list of child processes. If it finds a mismatch then it assumes it has a port conflict and it ends all of it's child processes and starts over. In the case of WebListener the port is actually opened by Http.Sys in the System process, so it never matches and always gets ended by platform handler.
HttpPlatformHandler will eventually need to support Http.Sys based back-end servers, but it's a non-trivial change for them so this isn't happening any time soon.
From @Tratcher on October 5, 2015 16:39
Right now all the tests run with Kestrel. When I briefly tried WebListener some of the test cases failed. The logs showed WebListener starting fine, but it never served any requests and HttpPlatformHandler kept re-starting the back-end process until it gave up.
I've seen it work when published to full IIS, so it might be a test setup issue.
Copied from original issue: aspnet/IISIntegration#8
The text was updated successfully, but these errors were encountered: