FIWARE猎户座运行时错误

Question

我正在使用FIWARE猎户座（在码头图像中），我面临着丢失一些记录的可能性。我查看了日志，并出现了一些错误，如下所示：

time=Sunday 17 Dec 21:03:13 2017.743Z | lvl=ERROR | corr=N/A | trans=N/A | from=N/A | srv=N/A | subsrv=N/A | comp=Orion | op=safeMongo.cpp[287]:setStringVector | msg=Runtime Error (element 0 in array was supposed to be an string but type=3 from caller mongoSubCacheItemInsert:225)

根据http://fiware-orion.readthedocs.io/en/0.26.1/admin/logs/，这些错误（运行时）“可能导致Context Broker失败”和“应该使用适当的渠道向Orion开发团队报告”，这正是我正在做的事情。

任何帮助，将不胜感激。

非常感谢你提前。

编辑：猎户座版本是1.5.0-下一个

编辑：它已升级到1.10.0

编辑：执行ps ax |后grep contextBroker我收到以下结果：

23470 ?        Ssl    4:24 /usr/bin/contextBroker -fg -multiservice -dbhost mongodb

编辑：问题定期发生。实际上，它恰好发生在每一分钟：

time=Wednesday 20 Dec 20:50:27 2017.235Z
time=Wednesday 20 Dec 20:51:27 2017.237Z
etc.

Answer 1

Orion 1.5.0- next表示1.5.0（2016年10月发布）和1。6。0（2016年12月发布）之间的一些运行版本。在最好的情况下，您的版本是一年，这是相当多的时间。

因此，我建议您升级到最新的Orion版本（在撰写本文时，该版本为1.10.0，于2017年12月发布）。我们已经在1.6.0和1.10.0之间的变化增量中解决了一些“过度记录”问题，你提到的问题可能就是其中之一。

如果问题在升级后仍然存在，请在答案评论中告知它，我们将继续进行调试。

Answer 2

诊断

60秒周期恰好是具有默认配置的订阅缓存刷新间隔（您的CLI确认您没有使用订阅缓存的不同设置）。

详细查看line refered by the log trace in Orion 1.10.0 source code：

setStringVectorF(sub, CSUB_CONDITIONS, &(cSubP->notifyConditionV));

日志错误意味着Orion期望数据库中订阅集合的文档中的CSUB_CONDITIONS字段的字符串数组，但是数组中的一些元素（或所有元素）不是字符串而是对象（类型3表示对象，作为BSON specification细节）。

CSUB_CONDITIONS恒定corresponds到DB的conditions场。请注意，此字段在Orion 1.3.0中已更改。在1.3.0之前，for instance 1.2.0，它是一个对象数组：

"conditions" : [
    {
        "type" : "ONCHANGE",
        "value" : [ "temperature " ]
    }
]

From 1.3.0 on，它被简化为一个字符串数组：

"conditions" : [ "temperature" ]

所以我的假设是，在过去的某个时刻，Orion实例更新了1.3.0边界但没有应用the procedure to migrate data（或者程序已经应用但在某种程度上失败了）。

解

鉴于您处于Orion数据库中的数据可能不一致的情况，最干净的解决方案是删除您的数据库。或者，至少，qazxsw icollection。

但是，只有在您可以轻松地重新生成要删除的数据的情况下，才可能这样做。如果这不可行，您可以尝试使用csubs。特别是，the procedure to migrate data脚本应该解决问题，虽然我建议应用完整的程序，以修复其他潜在的不一致。

考虑到迁移过程旨在在开始使用新的Orion版本之前应用。您似乎一直在使用1.3.0之前的Orion和1.3.0之前的数据，因此您的数据可能会以某种意外的方式演变，但程序无法修复。无论如何，即使在这种情况下，程序总比没有好:)

请注意，如果您使用的是csub_merge_condvalues.py（multiple services CLI参数似乎如此），则必须将清理/迁移过程应用于每个服务数据库。