0

Orion Context Broker v. 0.11.0 发生此错误。

我一直在 FIWARE 测试平台中运行 Orion Context Broker 的一个实例，几个小时后，Orion Context Broker 停止响应。但是，它不会崩溃，即在使用以下命令查询上下文代理的状态时：

/etc/init.d/contextBroker status

它将以“正在运行”响应。

但是，它不会响应向它发出的任何 http 请求。例如，使用上下文代理直接在 VM 上运行的完整性检查将失败：

wget http://localhost:1026/version

停止和启动 orion 或重新启动 orion 并不能解决问题。重新启动 linux VM 本身可以解决问题，直到它再次因相同问题停止工作。

我正在运行大约 40 个实体的持续活动，总共有大约 100 个不同的属性。我平均每 5 秒更新约 100 个属性，这被封装在大约 1-40 个请求中，同时向 Orion 上下文代理的 updateContext 操作发送。

我目前有一个订阅者订阅所有实体的所有属性的 ONCHANGE 事件（使用正则表达式）。

我仍然可以通过 SSH 连接到虚拟机，但是，一段时间后感觉响应速度较慢，这让我相信这可能是某种内存泄漏。

此外，当向代理运行 updateContext 请求时，随着时间的推移，这些请求开始感觉越来越不响应。（也就是说，刚重新启动代理后，所有操作总是很快完成，但是，一段时间后，它们需要更长的时间才能完成）。

如果需要，我将能够提供额外的信息。

编辑：详细的使用统计

我们每 5 秒向上下文代理运行约 20 个 updateContext 请求。这些请求是并行发送的。每个请求都有 1 个带有 5-20 个属性的上下文元素（粗略估计！）。contextValue 中的每一个都是一个复杂的值，如下所示：

<Measurement>
  <Value>20.53</Value>
  <Timestamp>2014-05-08T18:03:00Z</Timestamp>
</Measurement>

我们运行一个订阅者，该订阅者最初使用正则表达式在所有实体和所有属性上订阅上下文代理 10 分钟。我们每 5 分钟更新一次订阅，以便在应用程序处于活动状态时对其进行维护。（使用更新订阅操作）。

我们根本不使用任何同步操作来查询上下文数据。

我们使用硬件配置在 FIWARE 测试平台上运行上下文代理：

RAM:  4096MB
VCPUs:  2 VCPU
Disk:  10GB

它在 CentOS 版本 6.3 (Final) 上运行

4

2 回答 2

1

这可能是安装和管理手册中记录的自发二进制损坏问题的症状。

请查看https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_Installation_and_Administration_Guide#Diagnosis_Procedures部分的“诊断自发二进制损坏问题”部分为了检查它。

编辑：二进制损坏似乎是由预链接软件引起的。我们已在上述链接中添加了有关如何永久禁用预链接以避免此问题的信息。

编辑：从 Orion 0.14.1 开始，预链接排除文件包含在 RPM 中，所以这个问题不应该再发生了。

于 2014-04-30T10:53:22.357 回答
0

如果上一个答案不能解决问题，重新启动运行 Orion 的 VM 可能会有所帮助（请参阅Orion Context Broker 在几个小时后停止响应中的评论）。

于 2014-05-06T09:37:55.910 回答