Port aplikacji Microsoft Service Fabric już używany przez inną aplikację


Uruchamiamy lokalny klaster Service Fabric (5.4.145.9494), ale mamy kilka fajnych dziwactw. Zwykle za każdym razem, gdy uruchamiamy aplikację (zwłaszcza jeśli zawiera repliki), zauważamy, że usługi nie mogą się uruchomić przez większość czasu. Wewnątrz SF komunikat o błędzie nie jest tak opisowy (niezdrowa sekcja ...), jednak w dziennikach zdarzeń staje się oczywiste, że usługa nie może się uruchomić, ponieważ wybrany przez nią port jest już używany przez inną aplikację (od svchost do winit , prawie każda aplikacja).
W tym przypadku programiści NIE przypisują portu samodzielnie, więc w zasadzie SF musi to rozgryźć. W naszej konfiguracji przypisaliśmy zarówno porty tymczasowe, jak i porty aplikacji zgodnie z

https://docs.microsoft.com/en- ... ifest
https://docs.microsoft.com/en- ... ifest
i wypróbowaliśmy oba, ponieważ dokumentacja jest dość zagmatwana, jeśli chodzi o fakt, że porty aplikacji są podzbiorem portów efemerycznych, podczas gdy przykłady pokazują, że tak nie jest. Kolejna zabawna rzecz: ponieważ efemeryczna konfiguracja portu w zasadzie zmienia dynamiczny zakres portów samego okna, wszystko, co tu zmieniamy, zmienia również zakresy portów KAŻDEJ innej aplikacji działającej w systemie Windows.
Poza tym wygląda na to, że SF nie próbuje użyć innego portu, gdy zauważy, że port jest już używany, więc też się nie naprawi. Prosty fragment dziennika zdarzeń:
transport 35d3ce77c0 failed to bind on 0.0.0.0:49160, error = 0x80072740, port 49160 already held by process 204

w tym przypadku proces 204 to spoolsv.exe, ale znowu może to być dowolny proces.
W tej chwili konfiguracja węzła jest ustawiona na:
<NodeType Name="NodeType0">    <Endpoints>        <ClientConnectionEndpoint Port="19000"/>        <LeaseDriverEndpoint Port="19002"/>        <ClusterConnectionEndpoint Port="19001"/>        <HttpGatewayEndpoint Port="19080" Protocol="http"/>        <HttpApplicationGatewayEndpoint Port="19081" Protocol="http"/>        <ServiceConnectionEndpoint Port="19003"/>        <ApplicationEndpoints StartPort="49152" EndPort="50000"/>        <EphemeralEndpoints StartPort="49152" EndPort="65534"/>    </Endpoints>

Ale jak wspomniano wcześniej, już próbowaliśmy umieścić ApplicationEndpoints w naszym własnym zakresie, co tego nie naprawi ;-).
Każda pomoc byłaby bardzo mile widziana ;-)
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Napotkaliśmy ten sam problem w naszym lokalnym środowisku kontroli jakości. Rozwiązaliśmy ten problem, upewniając się, że wartość określona dla [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ MaxUserPort] (

https://technet.microsoft.com/ ... 95661(v=exchg.80).aspx
https://technet.microsoft.com/ ... 95661(v=exchg.80).aspx). poniżej najmniejszego portu określonego w manifestach klastra Service Fabric.
Najpierw zmieniliśmy wartość MaxUserPort zgodnie z powyższą regułą, ale po ponownym uruchomieniu została zresetowana. Widząc to, dostosowaliśmy ApplicationEndpoints i EphemeralEndpoints klastra SF, a środowisko wykonawcze SF nie narzeka już.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się