Orion Context Broker在几个小时后停止响应

时间:2014-04-30 10:49:06

标签: fiware-orion fiware

Orion Context Broker的v.1.11.0发生了此错误。

我在FIWARE Testbed中运行了Orion Context Broker的实例,几个小时后,Orion Context Broker就停止响应。但是,它不会崩溃,也就是说,使用以下命令查询上下文代理的状态时:

/etc/init.d/contextBroker status

它会响应" Running"。

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

wget http://localhost:1026/version

停止并启动猎户座或重新启动猎户座,无法解决问题。重新启动Linux VM本身可以解决问题,直到它再次停止使用相同的问题。

我使用大约40个实体的常量活动运行,总共有大约100个不同的属性。我平均有大约100个属性,每5秒更新一次,这封装在大约1-40个请求中,同时发送给Orion Context Broker的updateContext操作。

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

我仍然可以通过SSH连接到VM,但是,一段时间后感觉响应性降低,这让我相信它可能是某种内存泄漏。

此外,随着对代理运行updateContext请求的时间过去,这些开始感觉响应越来越少。 (也就是说,在重新启动代理之后,所有操作总是很快完成,但是,一段时间后,它们需要更长时间才能完成)。

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

编辑:详细使用情况统计

我们每5秒向上下文代理运行~20个updateContext请求。这些请求是并行发送的。每个请求都有1个上下文元素,具有5-20个属性(粗略估计!)。 contextValue是一个复杂的值,如下所示:

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

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

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

我们使用硬件配置在FIWARE Testbed上运行上下文代理:

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

它在CentOS版本6.3(最终版)上运行

2 个答案:

答案 0 :(得分:1)

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

请看一下&#34;诊断自发的二进制腐败问题&#34; 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中,因此不应再出现此问题。

答案 1 :(得分:0)

如果上一个答案无法解决问题,重新启动运行Orion的VM可能会有所帮助(请参阅Orion Context Broker stops responding after some hours上的评论)。