Тренер службы или службы службы становится недоступным в случайном порядке после обновления до SDK 2.3.301

После обновления с Service Fabric SDK 2.0.135 до 2.3.301 мы начали сталкиваться с ситуациями, когда актер или услуга Service Fabric недоступен, несмотря на то, что он проявляет себя как здоровый в Service Fabric Explorer. Как только в этом состоянии любой вызов актера или услуги через ActorProxy или ServiceProxy будет висеть в течение 5 минут, прежде чем, наконец, дать исключение TimeoutException. Когда-то в этом состоянии актер или служба никогда не восстанавливаются сами по себе - даже если оставить на час. Единственным решением является reset node (s), на котором находится актер или служба, передислоцировать актер или службу (точно такой же EXE), reset весь кластер или перезагрузить все кластерные машины.

Обычно он переходит в это состояние после развертывания или повторного развертывания приложения SF.

В последний год работы с Service Fabric (с SDK v1.3) у нас никогда не было этой проблемы. Он начался только после перехода на 2.3.301.

Кажется, случается случайно и непоследовательно. Какое из наших 13 SF-приложений в нашем решении получило эффект, также является случайным.

Есть ли у кого-нибудь идеи о том, как мы можем это решить? Это похоже на ошибку в последней версии Service Fabric, но, возможно, мы делаем что-то не так с нашей стороны.

Любая помощь приветствуется.

Ниже приводится много дополнительной информации, которая, я надеюсь, будет полезна для понимания того, с чем мы сталкиваемся с этой проблемой.

Большое спасибо

Шаги

У меня действительно нет шагов для последовательного воспроизведения проблемы. Это просто то, что я наблюдаю иногда.

Я скомпилировал, а затем повторно развернул свой проект SF из Visual Studio (Debug → Start Without Debugging)
Visual Studio говорит, что он успешно развернул проект
Сервис Fabric Explorer показывает все мои сервисы как "Здоровые", включая привязку данных
В проекте SF есть 2 участника, которые являются частью одного EXE. Сервис Fabric Explorer показывает, что каждый из этих участников работает на разных узлах.
Диспетчер задач Windows показывает две запущенные копии EXE, что имеет смысл, поскольку есть два узла, на которых выполняется EXE.

Аналогично, наш QA испытывает проблему после развертывания на Azure напрямую с помощью PowerShell. (Он не развертывается из Visual Studio.)

Обновить

Visual Studio заявляет, что развертывание прошло успешно
Сервис Fabric Explorer показывает, что все здорово
Диспетчер задач показывает две запущенные копии EXE

Когда я вижу отказ

У меня есть одна служба SF, вызывающая другую службу SF, используя классы ServiceProxy или ActorProxy. Мы делаем это на протяжении всего нашего решения с комбинацией из 13 различных приложений и около 25 различных сервисов и актеров. Он успешно работал с тех пор, как мы начали работать с Service Fabric SDK v1.3 в ноябре 2015 года.

Теперь, после обновления до 2.3.301, у нас есть периодическое появление случайного Актера или Службы, попадающих в состояние, когда он не отвечает на вызов метода при вызове из ServiceProxy или ActorProxy. После 5 минут висит, мы получаем исключение System.Timeout со следующим сообщением:

Это может произойти, если сообщение отключено, когда услуга занята или ее длинная работает и занимает больше времени, чем сконфигурировано Операция Тайм-аут.

Обратите внимание, что служба НЕ занята и не выполняет долговременную работу. Как актер, служба вообще не выполняет никаких текущих операций. Он просто раскрывает общедоступные методы, которые могут использовать другие службы. Он не срабатывает с самого первого вызова.

Фактически, трассировка показывает нам, что даже первая строка метода в актере никогда не вызывается. Как будто инфраструктура связи службы Fabric не может передать сообщение.

При запуске

За последние 12 месяцев мы никогда не видели эту проблему.

Теперь мы часто сталкиваемся с этой проблемой и в самых разных условиях после обновления Service Fabric на прошлой неделе.

Мы обновляемся до Service Fabric SDK 2.3.301.9590 и Service Fabric 5.3.301.9590.

Сначала каждый разработчик в команде столкнулся с проблемой самостоятельно, и каждый думал, что это временная проблема только с нашими машинами. Сервисная ткань имеет некоторые проблемы, поэтому мы просто принимаем это и продолжаем. Но потом мы начали жаловаться друг другу и поняли, что все мы это видим. Даже наши QAs видят это в облаке на нашей среде, которая скоро будет производиться.

Опять же, это только началось, когда мы обновили последнюю версию Service Fabric на прошлой неделе.

Ранее мы запускали Service Fabric SDK 2.0.135.

Мы обновили нашу кодовую базу, установив SDK v 2.3.301, открыв каждое из наших решений и разрешив Visual Studio выполнить обновление.

Среда

Я запускаю новую установку Windows 10 Enterprise (установленную менее 2 недель назад) на i7 с 16 гигабайтами оперативной памяти. У меня есть новая версия Visual Studio 2015 Update 3 и SF 2.3.301.9590. Я установил все чистое. Нет обновлений.

Это также происходит на всех моих коллегах (различного возраста, конфигурации и "свежести" ). Это случается спорадически для каждого из нас.

Наиболее критически это происходит и на наших виртуальных машинах Service Fabric на Azure. Это машины, которые наш QA создал около месяца назад, используя стандартные шаблоны для виртуальных машин Service Fabric на Azure. У него было предустановленное 5.3.301.9590. Он не вручную устанавливал обновления в Service Fabric. Наше приложение на основе SF не встретило этой проблемы с Azure (или нашими собственными машинами-разработчиками) до тех пор, пока разработчики не перешли на новую версию.

Это не моя машинная штука, и она не изолирована от среды разработки. Единственное последовательное изменение для всех нас - это обновление версии SF.

Причина

Мы не знаем, что его вызывает.

Обычно это происходит сразу же после развертывания нового приложения SF. Да, мы ждем обычных 2 или 3 минут, которые понадобится для того, чтобы SF "проявил себя" после развертывания. Мы оставили его на час или больше, и он просто никогда не работает.

А я думаю, что у меня была служба SF, которая отлично работала, а затем внезапно перестала работать, но это было до того, как мы поняли, что есть проблема, поэтому я ее не искал. Я не могу быть уверен.

Рабочие места

Как только у нас будет служба SF в этом "недоступном" состоянии, Service Fabric снова не вернется из этого состояния. Приложение полностью непригодно. С разной степенью успеха мы делаем следующее:

Повторно разверните недоступное приложение SF
Перезагрузите узлы (через проводник службы Fabric, перейдя к node, нажав кнопку с многоточием и нажав кнопку "Перезапустить" ) которые размещают недоступные службы SF и участников.
Перезагрузите весь кластер SF (Stop, Start)
Перезагрузите все машины под управлением SF node
Reset весь кластер и повторно разверните все (последнее, но это был необходим несколько раз)

Интересно, что не помогает диспетчер задач, чтобы убить оскорбительные процессы. Если я убью процесс нарушения, Service Fabric перезапустит его (как и ожидалось), но он все равно не будет отвечать на сообщения.

Таким образом, проблема, похоже, связана с самой службой Fabric, а не с EXE.

Конечно, эти арантные "решения" вообще, потому что они оставляют наше приложение недоступным до тех пор, пока SF не сможет перезапустить/перебалансировать. Даже перезапуск нескольких узлов сбивает кучу вещей в автономном режиме.

По сути, это шоу-стоппер для нас. Мы не можем поместить наше приложение в производство (или даже бета) с Service Fabric, ведущим себя таким образом.

Исключение С# при использовании прокси-сервера службы или прокси-сервера Actor:

JSON-рендеринг Исключения, брошенного ActorProxy или ServicePRoxy

"exception": {
    "ClassName": "System.TimeoutException",
    "Message": "This can happen if message is dropped when service is busy or its long running operation and taking more time than configured Operation Timeout.",
    "Data": null,
    "InnerException": null,
    "HelpURL": null,
    "StackTraceString": "   at Microsoft.ServiceFabric.Services.Communication.Client.ServicePartitionClient`1.<InvokeWithRetryAsync>d__7`1.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Microsoft.ServiceFabric.Services.Remoting.Client.ServiceRemotingPartitionClient.<InvokeAsync>d__8.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.<InvokeAsync>d__0.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Microsoft.ServiceFabric.Services.Remoting.Builder.ProxyBase.<ContinueWithResult>d__7`1.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at RenderingCachingEngine.RenderingCachingEngine.<Render>d__10.MoveNext() in C:\\Code\\Ink\\Dev\\Current\\Source\\Rendering Service Fabric\\RenderingCachingEngine\\RenderingCachingEngine.cs:line 381",
    "RemoteStackTraceString": null,
    "RemoteStackIndex": 0,
    "ExceptionMethod": "8\nMoveNext\nMicrosoft.ServiceFabric.Services, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35\nMicrosoft.ServiceFabric.Services.Communication.Client.ServicePartitionClient`1+<InvokeWithRetryAsync>d__7`1\nVoid MoveNext()",
    "HResult": -2146233083,
    "Source": "Microsoft.ServiceFabric.Services",
    "WatsonBuckets": null
  }

Здесь представлен JSON-рендеринг информации о сервисе:

  "serviceFabricInfo": {
    "serviceFabricServiceName": "fabric:/Rendering/RenderingCachingEngine",
    "serviceFabricServiceTypeName": "RenderingCachingEngineType",
    "serviceFabricReplicaId": 131225099453058851,
    "serviceFabricPartitionId": "e400087d-8a08-4dab-bcdd-1f5ce82f374f",
    "serviceFabricApplicationName": "fabric:/Rendering",
    "serviceFabricApplicationTypeName": "RenderingType",
    "serviceFabricNodeName": "_Node_4"
  }

Журналы просмотра событий при повторном развертывании

Средство просмотра событий Windows показывает заметные журналы в разделе "Журналы приложений и служб → Microsoft-Service Fabric → Admin".

При повторном развертывании обновленной версии моего приложения произошли следующие журналы (обратите внимание, что DataBinding.exe - это имя EXE, содержащего мои два участника SF):

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:38:53 PM
Event ID:      256
Task Category: Common
Level:         Error
Keywords:      Default
User:          NETWORK SERVICE
Computer:      shayward10.ovx.local
Description:
WriteNode failed. HRESULT=-2147467259, Output=CustomOutput
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>256</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:38:53.678587200Z" />
    <EventRecordID>7620</EventRecordID>
    <Correlation />
    <Execution ProcessID="4440" ThreadID="7360" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
  <EventData>
    <Data Name="id">
    </Data>
    <Data Name="type">XmlLiteWriter</Data>
    <Data Name="text">WriteNode failed. HRESULT=-2147467259, Output=CustomOutput</Data>
  </EventData>
</Event>

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:38:54 PM
Event ID:      23073
Task Category: Hosting
Level:         Warning
Keywords:      Default
User:          SYSTEM
Computer:      shayward10.ovx.local
Description:
ServiceHostProcess: DataBinding.exe for ApplicationId 805915c7-456c-49d3-af95-62cc44650664 terminated unexpectedly with exit code 3221225786 on node id bf865279ba277deb864a976fbf4c200e
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>23073</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>90</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:38:54.820567800Z" />
    <EventRecordID>7621</EventRecordID>
    <Correlation />
    <Execution ProcessID="6944" ThreadID="3812" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="id">bf865279ba277deb864a976fbf4c200e</Data>
    <Data Name="AppId">805915c7-456c-49d3-af95-62cc44650664</Data>
    <Data Name="ReturnCode">3221225786</Data>
    <Data Name="ProcessName">DataBinding.exe</Data>
  </EventData>
</Event>

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:38:56 PM
Event ID:      256
Task Category: Common
Level:         Error
Keywords:      Default
User:          NETWORK SERVICE
Computer:      shayward10.ovx.local
Description:
WriteNode failed. HRESULT=-2147467259, Output=CustomOutput
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>256</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:38:56.261857600Z" />
    <EventRecordID>7627</EventRecordID>
    <Correlation />
    <Execution ProcessID="4440" ThreadID="8564" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
  <EventData>
    <Data Name="id">
    </Data>
    <Data Name="type">XmlLiteWriter</Data>
    <Data Name="text">WriteNode failed. HRESULT=-2147467259, Output=CustomOutput</Data>
  </EventData>
</Event>

Журналы просмотра событий, когда он отключен

Как только служба находится в недоступном состоянии, попытка вызвать ее дает следующий журнал для каждого запроса (после ожидания в течение 5 минут):

Log Name:      Microsoft-ServiceFabric/Admin
Source:        Microsoft-ServiceFabric
Date:          11/2/2016 2:44:55 PM
Event ID:      44289
Task Category: FabricTransport
Level:         Warning
Keywords:      Default
User:          NETWORK SERVICE
Computer:      shayward10.ovx.local
Description:
Error While Sending Message : FABRIC_E_TIMEOUT
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-ServiceFabric" Guid="{CBD93BC2-71E5-4566-B3A7-595D8EECA6E8}" />
    <EventID>44289</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>173</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2016-11-02T18:44:55.349048200Z" />
    <EventRecordID>7629</EventRecordID>
    <Correlation />
    <Execution ProcessID="18600" ThreadID="8076" />
    <Channel>Microsoft-ServiceFabric/Admin</Channel>
    <Computer>shayward10.ovx.local</Computer>
    <Security UserID="S-1-5-20" />
  </System>
 <EventData>
    <Data Name="id">
    </Data>
    <Data Name="type">ServiceCommunicationClient</Data>
    <Data Name="text">Error While Sending Message : FABRIC_E_TIMEOUT</Data>
  </EventData>
</Event>

Ответ 1