小编Sha*_*aun的帖子

升级到SDK 2.3.301后,Service Fabric Actor或Service变为无法访问

从Service Fabric SDK 2.0.135升级到2.3.301之后,我们开始遇到Service Fabric actor或服务无法在Service Fabric Explorer中显示为健康状态的情况.一旦处于此状态,通过ActorProxy或ServiceProxy对actor或服务的任何调用将挂起5分钟,最后给出TimeoutException.一旦处于这种状态,演员或服务就不会自行恢复 - 即使离开一小时.唯一的解决方案是重置actor或服务所在的节点,重新部署actor或服务(完全相同的EXE),重置整个集群或重新引导所有集群计算机.

在部署或重新部署SF应用程序后,它通常会进入此状态.

在使用Service Fabric的最后一年(从SDK v1.3开始),我们从未遇到过这个问题.它仅在移至2.3.301之后才开始.

它似乎随机而且不一致.我们解决方案中的13个SF应用程序中的哪个应用程序也是随机的.

有没有人对我们如何解决这个问题有任何想法?这似乎是Service Fabric最新版本中的一个错误,但也许我们在最后做错了.

任何帮助表示赞赏.

下面是很多额外的信息,我希望这些信息有助于理解我们在这个问题上面临的问题.

非常感谢

脚步

我真的没有采取措施来始终如一地重现这个问题.这就是我有时观察到的.

  1. 我编译然后从Visual Studio重新部署我的SF项目(Debug - > Start Without Debugging)
  2. Visual Studio说它成功部署了该项目
  3. Service Fabric Explorer将我的所有服务显示为Healthy,包括Data-Binding
  4. 有问题的SF项目有2个参与者,它们是单个EXE的一部分.Service Fabric Explorer显示在不同节点上运行的每个actor.
  5. Windows任务管理器显示EXE的两个运行副本,这是有道理的,因为有两个节点运行EXE.

同样,我们的QA在使用PowerShell直接部署到Azure后遇到了问题.(他不从Visual Studio部署.)

回顾一下

  • Visual Studio表示部署成功
  • Service Fabric Explorer显示一切都很健康
  • 任务管理器显示EXE的两个运行副本

当我看到失败

我有一个SF服务使用ServiceProxy或ActorProxy类调用另一个SF服务.我们在整个解决方案中实现了这一目标,结合了13种不同的应用程序和约25种不同的服务和参与者.自从我们于2015年11月开始使用Service Fabric SDK v1.3以来,它已经成功运行.

现在,在升级到2.3.301之后,我们定期出现一个随机Actor或Service进入一种状态,当从ServiceProxy或ActorProxy调用时,它无法响应对方法的调用.挂起5分钟后,我们收到System.Timeout异常,并显示以下消息:

如果在服务繁忙或其长时间运行操作时丢弃消息并且花费的时间超过配置的操作超时,则会发生这种情况.

请注意,该服务不忙,也不执行长时间运行.作为演员,该服务根本不进行任何正在进行的操作.它只是暴露了其他服务可以使用的公共方法.它从第一次调用失败.

实际上,跟踪向我们表明,即使是actor中方法的第一行也永远不会被调用.就像Service Fabric通信基础设施无法传递消息一样.

什么时候开始

在过去的12个月里,我们从未见过这个问题.

现在,自上周升级Service Fabric以来,我们经常在各种条件下看到这个问题.

我们升级到Service Fabric SDK 2.3.301.9590和Service Fabric 5.3.301.9590.

起初,团队中的每个开发人员都独立地遇到了这个问题,每个人都认为这只是我们机器的一个短暂问题.Service Fabric确实存在一些问题,所以我们接受这个并继续前进.但后来我们开始互相抱怨,意识到我们都在看到它.即便是我们的QA也会在我们的环境中看到它即将投入生产.

同样,这只是在我们上周升级到Service Fabric的最新版本时才开始的.

以前,我们运行的是Service Fabric SDK 2.0.135.

我们通过安装SDK v 2.3.301升级了我们的代码库,打开了我们的每个解决方案并允许Visual …

c# azure visual-studio-2015 azure-service-fabric service-fabric-stateful

14
推荐指数
1
解决办法
2685
查看次数

Microsoft Service Fabric主机服务(FabricHostSvc)挂起

自2015年11月以来,我一直在使用Microsoft Service Fabric,但遇到了很多问题,但现在Service Fabric在我的开发机器上已经完全无法正常运行.卸载/重新安装没有帮助.

我正在使用1.5预览,并从那以后尝试2.0无济于事.

当我尝试从Visual Studio 2015 Update 1运行Service Fabric应用程序时,问题就出现了(正如我在过去几个月中已经完成了数百次).

我的机器是蓝屏的(我第一次看到Windows 10的蓝屏).重新启动后,我无法通过Visual Studio部署我的Service Fabric应用程序.PowerShell脚本失败,并显示以下消息:

启动服务FabricHostSvc.这可能需要几分钟...启动服务:无法启动服务'Microsoft Service Fabric Host Service(FabricHostSvc)'.

我进入SCM并发现"Microsoft Service Fabric Host Service"处于Starting状态.它停留了一个小时.我尝试多次停止和启动服务,每次挂起.

我卸载了Service Fabric(Service Fabric,SDK和Tools for VS)并重新安装了最新版本2.0,它也出现了同样的问题.

重启,同样的问题.

删除了c:\ SfDevCluster文件夹,同样的问题.

基于其他一些文章,我在卸载后寻找任何流浪性能计数器,但没有任何.

我尝试查看注册表,但名称中还有其他Azure组件"Fabric".如果我删除它们,我可能会管理我的Azure开发设置的其余部分.

现在......当我再次尝试启动服务时,它确实重新创建了SfDevCluster文件夹并给我一些日志.它似乎每分钟创建两个跟踪日志文件,它们具有完全相同的内容.

每次失败时,跟踪的最后一行是:

信息,11176,General.FabricSetup.Main,操作失败,错误0xffffffff

较早的跟踪(SF 1.5)似乎使用常量而不是错误的十六进制值.似乎表示无效的论点.

无论这种失败是什么,它似乎是我的困境的原因.不幸的是,错误完全没有用.

我试图避免重新安装Windows,因为这会耗费一整天的生产力.

任何帮助是极大的赞赏.

c# azure azure-service-fabric

8
推荐指数
1
解决办法
4039
查看次数

如果设置了 AutoDeleteOnIdle,服务总线是否删除没有过滤器/规则的主题订阅?

下午好。

我们使用服务总线主题作为发布/订阅系统的引擎。我们的逻辑涉及我们的 C# 服务通过订阅连接到一个主题。我们删除 $Default (TrueFilter) 并将 AutoDeleteOnIdle 设置为 5 分钟。

当系统的其他部分需要东西时,它们会告诉我们的 C# 服务,“我需要这个。” 然后 C# 服务添加新规则(通常是 CorrelationFilter)。

由于系统的那些相同部分不再需要东西,它们告诉我们的 C# 服务,“我不再需要它了。” C# 服务然后删除相应的规则。

因此,主题订阅仍然可以连接(通过 SubscriptionClient 对象完成)但根本没有规则。

问题

订阅“消失”了,我不知道为什么。毕竟,我有一个带有 SubscriptionClient 实例的活动订阅和一个回调函数。

然后,当我使用我的 SubscriptionClient 对象执行操作时,它会抛出 MessagingEntityNotFoundException。

在我看来,Service Bus 似乎是随机且任意地丢失或删除我的订阅。

服务总线对“空闲”的定义

我的理解是,只要与订阅有活动连接(在我的情况下,通过 SubscriptionClient 实例),订阅就不会“空闲”。即使没有感兴趣的消息通过,它仍然没有空闲,因此仍然没有被删除。如果消息在一天后到来,则 SubscriptionClient 实例将收到它。

这是我对不动态添加/删除规则的系统其他部分的经验。它运作良好。

但后来我开始想:

尽管已连接到订阅,Service Bus 是否将我的订阅视为空闲,因为它没有规则,因此不可能接收消息?然后服务总线会遵循 AutoDeleteOnIdle 属性并删除它吗?

如果上述情况属实,那么会添加一个 FalseFilter 作为 $Default 保持订阅有效吗?

任何见解和帮助将不胜感激。

非常感谢 - 肖恩

更新

我在 WinForms 应用程序中做了一个基本的测试,服务总线似乎有一些根本性的错误。或者,至少,我们的服务总线实例。

我有17个主题,如下:

  • d860ffbe-e9c6-4ede-b6e9-959be4373128/notify-0
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/notify-1
  • ...(你懂的)
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/notify-e
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/notify-f
  • d860ffbe-e9c6-4ede-b6e9-959be4373128/notify-root

notify-root 将它收到的所有消息转发到其他通知主题。我们这样做是为了分片。

所以...

我在 0 到 f 主题中的每一个上创建了 3 个订阅: …

c# servicebus azure azureservicebus azure-servicebus-topics

7
推荐指数
1
解决办法
1707
查看次数