问题标签 [orleans]

我正在努力让 Microsoft Orleans “Grains” 将事件放到 SignalR 总线上。有一个示例项目可以做到这一点，我已经链接到下面的 SignalR 集成。

在我看来，此示例使用来自 Azure Web 和 Worker 角色的元数据来枚举所有 Web 角色，并向每个角色显式发布消息。在我看来，如果 SignalR 的背板在 azure web 角色上正确配置，这不应该是必要的——一个 HubConnection/HubProxy 应该这样做。那正确吗？

事实上，当我仔细查看下面链接的文件并看到集线器本身的一些奇怪逻辑时，我想知道该示例是否起到了基本背板的作用。

我希望有更深入 SignalR 经验的人可以为我澄清这一点。

SignalR 集成示例：https ://orleans.codeplex.com/SourceControl/latest#src/samples/GPSTracker/GPSTracker.GrainImplementation/PushNotifierGrain.cs

我想知道在 Microsoft Orleans 中使用 log4net 的最佳做法是什么？应该在哪里初始化？

我正在尝试编写一个简单的奥尔良演示解决方案：

1. 我已经通过来自 github 的 .msi安装了 Orleans v1.0.0 。
2. 我创建了一个新的 Visual Studio 2013 解决方案。
3. 我创建了一个新的Orleans Grains Interface Collection类型项目。
4. 我创建了一个新的Orleans Grains Class Collection类型项目

在接口集合项目中，我可以输入 Orleans 和 VS2013 Intellisense 识别命名空间及其内容：

在类集合项目中，我不能：

为什么会发生这种情况，我该如何解决？

我正在使用 Microsoft Orleans SDK 的 v1.0.5 版本，并且正在遵循在独立筒仓中运行Microsoft Orleans 教程

它提出了以下建议：

如果您将grain collection项目设置为启动项目并按F5，您会注意到它是由一个名为“OrleansHost”的silo启动和托管的。...

但据我所知，Grain Collection Project 是一个类库，自编写教程以来，这种情况发生了变化（我注意到它使用旧的 OrleansClient 而不是 GrainClient）。

下面的主要方法：

我相信是针对 SiloHost 的。

我最近被介绍到奥尔良项目，目前正在做一些阅读和概念验证。

除了我遇到的几乎所有文章和教程都不能像现在这样（主要是由于 API 更改）这一事实之外，它们还需要安装 Orleans SDK；其中包含库、文档、项目模板等。

我决定用“硬方式”来做，并使用标准项目模板（控制台应用程序和类库）和 NuGet；OrleansHostWrapper在 Orleans 项目模板 ( )中的样板代码的帮助下。

有一件事我不知道该怎么做；这是生成Grain工厂/代理。当我运行筒仓时，我收到消息：

找不到为接口生成的工厂类型

有人可以帮忙吗？是否有另一种无需安装Orleans SDK 即可生成工厂的方法？

Azure Service Fabric 似乎专注于所有数据都可以放入 RAM 并且持久性用作后备存储的方案。Reliable Services 旨在将信息存储在 Reliable Collections 中，该集合使用日志检查点系统，将记录的信息写入 RAM。同时，对于 Reliable Actors，默认的 Actor 状态提供者是“Service Fabric 平台提供的分布式 Key-Value 存储”。这似乎表明同样的限制也适用。

但是，在某些情况下，人们可能希望将 Service Fabric 用于“热数据”，但将“冷数据”写入某种形式的永久存储。处理这种过渡的最佳做法是什么？

在奥尔良，这似乎是使用 Azure 表等持久性存储自动处理的。但似乎 Service Fabric 和 Reliable Collections 的主要设计目的是避免需要外部服务，从而增强数据局部性。当前的文档预计将数据移动到某个永久存储以进行灾难恢复和分析的可能性，但它没有讨论在持久性支持的内存中参与者和更永久的存储形式之间来回移动数据的可能性.

一个可能的答案是 Service Fabric 已经这样做了。也许 Reliable Dictionary 有一些内置机制，用于在持久支持的内存存储和永久存储之间切换。

或者，也许答案是必须自己管理。一种方法可能是让 Actor 跟踪它的“热”程度并根据需要切换其持久性存储。但这牺牲了 Actor 模型的好处之一，即 Actor 的自动分配和释放。类似地，我们可能会定期从 Reliable Dictionary 中删除项目并将其添加到其他一些持久性存储中，然后再将它们添加回来。不过，这同样需要了解何时进行过渡是有意义的。

几个例子可能有助于明确这一点：

(1) 假设我们正在实现一个有许多不同“房间”的多人游戏。我们不需要同时在内存中的所有房间，但我们需要将它们移动到内存中，并在玩家加入它们时使用本地持久性作为备份。

(2) 假设我们正在实现一个仅附加 B-Tree 作为数据库的一部分。诱惑是让每个 B-Tree 节点成为有状态的参与者。我们希望热 b-trees 保留在内存中，但当然整个索引不能在内存中。似乎这是一个已经为 DocumentDB 之类的东西实现的核心场景，但是从文档中我不清楚如何做到这一点。

我发现的一个相关问题是here。但这个问题集中在何时使用 Azure Service Fabric 与外部服务。我的问题是是否需要在它们之间进行转换，或者 Azure Service Fabric 是否已经具备此处所需的所有功能。

我正在使用 orleankka 在 orleans 框架之上编写一个小型机器学习引擎。我需要一个父子类关系，其中父级支持获取、设置、默认构造函数和序列化。我的尝试在 F# 中失败了。

更新：使用接口现在我只需要弄清楚图像通道对象的序列化。

上下文代码：

我应该直接实现序列化接口吗？如何用不同类型覆盖抽象值成员？还有其他建议吗？

在奥尔良，PlacementStrategy 是如何工作的？我看到 PlacementStrategy 有多种实现，包括 RandomPlacement、PreferLocalPlacement、ActivationCountBasedPlacement 和 StatelessWorkerPlacement。

我有几个问题，从如何使用它们到它们是如何实现的？如何指定呼叫应该是 Prefer-Local vs RandomPlacement？

我正在查看代码，但没有看到基于这些放置策略选择一个执行路径而不是另一个执行路径的代码。发生在哪里？

我知道这是一个常见问题，但我阅读了很多关于它的内容，但仍然无法决定哪个是我的案例更好的选择：

我需要设计一个具有相对较多原始字段的数据结构，例如“Person”，其中包含有关此人的大量信息。底层框架是 MS Orleans，预计在每个给定时间（在每台机器上）内存中都会有数十万个“Person”实例。起初我认为 struct 是更好的选择，因为 GC 压力和内存开销会更小。但是当我开始实现这个设计时，结果发现它很痛苦——“Person”有 4 个嵌套结构，每个都有大约 8 个字段（包括数组），而且我花了太长时间为每个实现 IEquatable，更不用说每一个微小的变化在其中一种结构中需要重构 IEquatable 实现和 ctors。

但后来我想，由于“Person”对象不会是短期对象，它们可能会被提升到第 1 代或第 2 代，所以 GC 压力可能没什么大不了的。至于（类的）内存开销 - 我可以忍受......

那么，任何人都可以分享他们对这个案例的看法吗？MSDN 建议不要对大于 32 字节的对象使用结构，我的对象很容易超过。

我正在测试Microsoft Orleans作为分布式计算框架的可行性。似乎它可能会起作用，但是我想知道如何设置给定筒仓中的最大活性谷物数量？

我的 grain 不会纯粹受 CPU 限制，而是会执行一些 IO 和其他相关任务。我担心如果我让它疯狂运行，它会启动大量实例，这会使整个事情陷入困境。

这样的筒仓配置可能吗？