在Orion Context Broker的v.1.1.0.0中发生此错误 .
我一直在FIWARE Testbed中运行Orion Context Broker的一个实例，几个小时后，Orion Context Broker就会停止响应 . 但是，它不会崩溃，也就是说，使用以下命令查询上下文代理的状态时：
/etc/init.d/contextBroker status
它将以“Running”响应 .
但是，它不响应向它发出的任何http请求 . 例如，使用上下文代理直接在VM上运行的健全性检查将失败：
wget http://localhost:1026/version
停止并启动orion或重新启动orion，无法解决问题 . 重新启动Linux VM本身可以解决问题，直到它再次停止工作并出现同样的问题 .
我正在运行大约40个实体的常量活动，总共有大约100个不同的属性 . 我平均有大约100个属性，每5秒更新一次，这封装在大约1-40个请求中，同时发送到Orion Context Broker的updateContext操作 .
我目前有一个订阅者在所有实体的所有属性上订阅ONCHANGE事件（使用正则表达式） .
我仍然可以通过SSH连接到VM，但是，它在一段时间后感觉不太敏感，这让我相信它可能是某种内存泄漏 .
此外，随着对代理运行updateContext请求的时间过去，这些开始感觉响应越来越少 . （也就是说，在重新启动代理之后，所有操作总是很快完成，但是，一段时间后，它们需要更长的时间才能完成） .
如果需要，我将能够提供额外的信息 .
EDIT: Detailed usage statistics
我们每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 回答
这可能是安装和管理手册中记录的自发二进制损坏问题的一个解决方案 .
请查看https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-Orion_Context_Broker-_Installation_and_Administration_Guide#Diagnosis_Procedures部分的"Diagnose spontaneous binary corruption problems"部分以查看它 .
EDIT ：二进制损坏似乎是由prelink软件引起的 . 我们已在上述链接中添加了有关如何永久禁用预链接以避免此问题的信息 .
EDIT ：来自Orion 0.14.1，预链接排除文件包含在RPM中，因此不应再出现此问题 .
如果上一个答案无法解决问题，重新启动运行Orion的VM可能会有所帮助（请参阅Orion Context Broker stops responding after some hours处的评论） .