App Microsoft Service Fabric, Déjà occupé

Nous lancons un cluster local Service Fabric (5.4.145.9494), Mais nous avons des caractéristiques amusantes. Généralement chaque fois que nous exécutons l'application (surtout si cela contient des répliques), Nous remarquons que les services ne peuvent pas être lancés la plupart du temps. À l'intérieur SF Le message d'erreur n'est pas si descriptif (Section malsaine ...), Cependant, dans les journaux d'événement, il devient évident que le service ne peut pas démarrer, car le port sélectionné par elle est déjà utilisé par une autre application. (du processus svchost avant que winit Pratiquement n'importe quelle application).

Dans ce cas, les développeurs ne prescrivent pas le port eux-mêmes, donc principalement SF Doit savoir. Dans notre configuration, nous avons été prescrits à la fois des ports temporaires et des ports d'application en fonction de
https://docs.microsoft.com/en- ... ifest
Et nous avons essayé les deux options, car la documentation est assez confus que les ports de port sont un sous-ensemble de ports éphémères, tandis que des exemples montrent que ce n'est pas le cas. Une autre chose amusante: puisque la configuration des ports éphémères change essentiellement la gamme dynamique des ports de la fenêtre elle-même, tout ce que nous changeons ici modifie également les gammes de ports de toute autre application fonctionnant à l'intérieur. Windows.

À côté de cela, il semble que SF N'essaie pas d'utiliser un autre port lorsque le port est déjà utilisé, il ne se corrigera pas non plus. Fragment simple du journal des événements:

transport 35d3ce77c0 failed to bind on 0.0.0.0:49160, error = 0x80072740, port 49160 already held by process 204

Dans ce cas, le processus 204 - c'est spoolsv.exe, Mais encore une fois, cela peut être n'importe quel processus.

Pour le moment, la configuration du nœud est définie sur:

<nodetype name="NodeType0">
<endpoints>
<clientconnectionendpoint port="19000"></clientconnectionendpoint>
<leasedriverendpoint port="19002"></leasedriverendpoint>
<clusterconnectionendpoint port="19001"></clusterconnectionendpoint>
<httpgatewayendpoint port="19080" protocol="http"></httpgatewayendpoint>
<httpapplicationgatewayendpoint port="19081" protocol="http"></httpapplicationgatewayendpoint>
<serviceconnectionendpoint port="19003"></serviceconnectionendpoint>
<applicationendpoints endport="50000" startport="49152"></applicationendpoints>
<ephemeralendpoints endport="65534" startport="49152"></ephemeralendpoints>
</endpoints>

Mais, comme on l'a dit plus tôt, nous avons déjà essayé de mettre ApplicationEndpoints Dans votre propre gamme qui ne corrigera pas ;-).

Toute aide sera la bienvenue. ;-)
</nodetype>
Invité:

Blanche

Confirmation de:

Nous avons rencontré le même problème dans notre environnement de contrôle de la qualité local. Nous avons résolu le problème, en veillant à ce que la valeur spécifiée pour [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ MaxUserPort] (
(v=exchg.80).aspx[/url]
). Sous le plus petit port spécifié dans le manifeste de cluster Service Fabric (et).

D'abord nous avons changé la valeur MaxUserPort Conformément à la règle ci-dessus, mais après avoir redémarré sa valeur a été réinitialisée. Voir cela, nous avons adapté les valeurs ApplicationEndpoints et EphemeralEndpoints Grappe SF, et environnement environnemental SF Ne se plaint plus.

Pour répondre aux questions, connectez-vous ou registre