问题标签 [fault-tolerance]

Firefox 在呈现糟糕的 HTML 时有一定的容忍度。这意味着即使省略了结束标记，HTML 也会像一切正常一样显示。当使用 JavaScript 在当前页面中操作或添加内容时，这种容差方面尤其重要。

由于我使用 Firefox 作为我的主要测试/开发浏览器，我不止一次被这种行为所困扰，其后果是在“更严格”的浏览器中失去功能。例如，Microsoft Internet Explorer 中的相同代码无法生成任何可见的输出，因为在添加的内容中提到了缺少的标签。

现在的问题是，有没有办法告诉 Firefox 对接受的 HTML 更加严格并且失败而不是“猜测修复”（特别是当通过 JavaScript 添加 HTML 时）？

PS：我试过玩 DOCTYPE 但结果是一样的。

我有客户端/服务器应用程序，客户端应用程序将在其中打开文件。这些文件被分割成块，并发送到服务器。

客户端不仅发送文件块，还发送其他数据。每条消息（数据或文件块）都有一个优先级。

所有消息都会根据它们的优先级缓冲并写入 TCP 流。当前，只要文件完全发送或接收，输入和输出流就会在两侧（客户端/服务器）关闭。这意味着只要发送文件，流就会保持打开状态。

允许 TCP 连接失败，因为它将重新连接并恢复消息发送，因此，流将在某个时候关闭。

但是，例如，如果 JVM 会被杀死，那么流将不会被清理。

我解决这个问题的第一个想法是在终结器中添加清理代码，但我知道当 JVM 被杀死（或者如果 System.exit 被调用）时，这些代码可能不会运行。

我的第二个想法是重写应用程序的一部分，并且只使用流，只要它需要读/写一个块。因此，我最终会打开/关闭文件的次数与块的次数一样多。这种方法的优点是允许我使用 try-catch-finally 结构，但我有一种打开和关闭文件的直觉，这通常意味着相当多的开销。

那么当设计不允许finally{}块时，如何清理资源呢？还是应该避免这样的设计，也许以类似于我所描述的方式？

我还担心打开的文件数量可能与优先级一样多（理论上是无限的）。

大多数文件通常只有几 KiB，但在某些情况下，它们可能会达到几 GB。

提前感谢您的意见。

编辑：添加图像

注意：这个问题很大程度上受到我构建的 Web 应用程序的主要要求的影响：高可用性和容错性。所有其他要求（如可扩展性和用户数量）在这里都不是问题。

我从这个社区的一位成员那里得到并建议使用 Erlang Web 服务器作为我的 Web 应用程序的后端。

建议是我可以使用 Mochiweb 作为后端，使用 Django/Ruby on Rails 作为前端，使用 JSON 和面向服务的模型。

我能理解的这种方法的唯一明显优势是前端部分的开发“照常”——常规的 MVC 东西、Ru​​by on Rails 或任何其他人选择的通用框架。

但是其他优势呢？它们真的存在吗？

当然，Erlang/OTP 为所讨论的系统增加了容错能力，但是添加 Web 前端层不会将这个容错级别降低到低得多的水平吗？

难道我们不是通过将 Ruby on Rails 与 Mochiweb 耦合来引入“单点故障”吗？当然，Mochiweb 可以处理故障，但是如果前端出现问题怎么办？

编辑 - 实现语言是 Java。

我想做一个简单的容错系统。

• 对象 A - 此对象包含系统的决策逻辑。
• 对象 B - 此对象将用于控制容错

我最初的想法是让对象 A 使用要保存到数据文件的变量值更新对象 B。然后对象 B 将创建一个数据文件，该文件将保存到平台系统的硬盘驱动器中。

我的问题是：如何使用对象变量的值创建数据文件，然后从数据文件中检索这些变量？当他们被调用时。

我很高兴将变量值写入记事本文件，然后从文件中调用它们

我正在使用 solr 进行复制。我有一个索引数据的主机和两个从主机提取索引并响应查询的从机。

我的问题是，如何创建容错架构？我的意思是当主服务器崩溃时我该怎么办？

使用复制中继器是一种选择，但我正在寻找更好的解决方案。

任何帮助将不胜感激。

我不确定这是否是 jsoncpp 的特定事物，或者是如何使 C++ 库表现更好的一般范例。基本上我得到了这个跟踪：

当输入不好时会发生这种情况。当输入（通过 memcached 来自我的另一个应用程序）发生错误时，我想处理此错误。你知道，优雅地。可能类似于“错误：项目 15006 的输入错误”进入日志。不会使我的整个 JSON 字符串处理任务崩溃。

这只是一个写得不好的库还是可以更巧妙地配置它？

编辑：这是一些调用代码：

我知道使用 Akka 进行适当的集群是 Akka 2.1 的重点，但是需要用现在可用的东西来构建一些东西。

我有一个多节点 Akka 设置，并希望优雅地处理远程演员死亡。但是，由于系统是对称的并且不应该有单点故障，我不确定如何正确设置主管层次结构。监督者不能与被监督的参与者在同一个 Akka 实例上，因为我需要处理整个 Akka 节点的终止，但是如果我将监督者放在一个单独的节点上，我现在冒着孤立或终止被监督的参与者的风险运行主管的节点死亡。

我真正想要的是一个集群监督者，其中任何 Akka 节点（或其中 n 个）上的参与者可以处理一组参与者的监督，以避免任何单点故障。在 Akka 2.0 中这样的事情可能吗？如果没有，获得相同效果的最佳方法是什么？

假设一个监督者正在监督一个远程参与者。如果远程actor由于其整个Akka节点已终止而死亡，是否有可能在新的Akka节点上复活actor，保持所有现有的ActorRefs都活着？

根据 Erlang 的“让它崩溃”的理念，如果一个进程无法分配继续其操作所需的内存，人们会期望整个 VM 不会崩溃。事实上，如果系统有一个启发式方法来杀死某个进程以释放一些内存，那么其他一些进程会处理这个并恢复。根监督者可能不太可能被启发式方法杀死。

这与大多数现代流行语言形成鲜明对比，后者只是死掉或让操作系统选择做什么。

在 Erlang中实际上是如何处理内存不足的？

我有一个由 LiteSoft.org 编码的 P2P 应用程序。我希望在此应用程序中实现领导者选举系统。在我开始之前，我必须有一个容错系统，该系统将包括向对等方（在本例中为协调器）发送请求，以检查他是否仍在响应。我如何实现一个计时器系统来发送请求？