FIWARE Orion Runtime Error

0
votes

I am using FIWARE Orion (in a docker image) and I am facing with the possibility of losing some records. I looked in the log and came with a number of errors like the following:

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)

According to http://fiware-orion.readthedocs.io/en/0.26.1/admin/logs/ these kind of errors (Runtime) "may cause the Context Broker to fail" and "should be reported to the Orion development team using the appropriate channel" and this is exactly what I am doing.

Any help, will be highly appreciated.

Thank you very much in advance.

EDIT: Orion version is 1.5.0-next

EDIT: It has been upgraded to 1.10.0

EDIT: After executing ps ax | grep contextBroker I receive the following results:

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

EDIT: The problem occurs periodically. Actually, it takes place exactly every minute:

time=Wednesday 20 Dec 20:50:27 2017.235Z
time=Wednesday 20 Dec 20:51:27 2017.237Z
etc.
2
fiware-orion
Just to confirm... which Orion version are you using? By the URL you mention it may be 0.26.1, but I would like to confirm. Thx! – fgalan
Thank you fgalan for the immidiate response. By executing the command curl localhost:1026/version in my system, I receive the response: "orion" : { "version" : "1.5.0-next", – Anastasios Oikonomidis
You can update to the latest version. In CentOS, I think yum install contextBroker should work... – Dalton Cézane

2 Answers

1
votes

Orion 1.5.0-next means some running version between 1.5.0 (released in October 2016) and 1.6.0 (released in December 2016). In the best case, your version is one year old, which is pretty much time.

Thus, I recommend you to upgrade to the newest available Orion version (in the moment of writting this, that version is 1.10.0, released in December 2017). We have solved some "overlogging" problems in the delta of changes between 1.6.0 and 1.10.0 and the one you mention could be one of them.

If the problem stills after upgrading, tell about it in a comment to the answer and we'll keep debuging.

1
votes

Diagnosis

The 60 seconds periodicity is exactly the subscriptions cache refresh interval with default configuration (your CLI confirms your are not using different setting for subscriptions cache).

Looking in detail to the line refered by the log trace in Orion 1.10.0 source code:

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

The log error means that Orion expects an array of strings for the CSUB_CONDITIONS field in a document of the subscription collection at database, but some of the elements in the array (or all) aren't strings but a objects (type 3 means object, as BSON specification details).

CSUB_CONDITIONS constant corresponds to conditions field at DB. Note this field changed at Orion 1.3.0. Before 1.3.0, for instance 1.2.0, it was an array of objects:

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

From 1.3.0 on, it was simplified to an array of strings:

"conditions" : [ "temperature" ]

So my hypothesis is that in some moment in the past that Orion instance was updated crossing the 1.3.0 boundary but without applying the procedure to migrate data (or the procedure was applied but failed in some way).

Solution

Given that you are in a situtation in which your data at Orion database is probably inconsistent, the cleanest solution would be to remove your database. Or, at least, the csubscollection.

However, this is possible only in the case you can regenerate the data to be deleted in an easy way. If that is not feasible, you can try with the procedure to migrate data. In particular, the csub_merge_condvalues.py script should fix the problem although I'd recommend to apply the full procedure in order to fix other potential inconsistencies.

Take into account that the migration procedure was designed to be applied before start using the new Orion version. It seems you have been using post-1.3.0 Orion with pre-1.3.0 data for a time, so your data can have evolved in some unexpected way the procedure couldn't fix. Anyway, even in this case the procedure is better than nothing :)

Note that if you are using multiple services (it seems so for the -multiservice CLI parameter) you have to apply the clean/migration procedure to every per-service database.