我正在使用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.
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之间的变化增量中解决了一些“过度记录”问题,你提到的问题可能就是其中之一。
如果问题在升级后仍然存在,请在答案评论中告知它,我们将继续进行调试。
诊断
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参数似乎如此),则必须将清理/迁移过程应用于每个服务数据库。