FIWARE Orion 런타임 오류

Question

FIWARE Orion (도커 이미지에서)을 사용 중이며 일부 기록을 잃을 가능성이 있습니다. 나는 로그에보고와 같은 오류의 숫자와 함께 다음

이

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/ 오류 이런 종류의 (런타임)에 따르면 오리온에게보고해야합니다 ""상황에 맞는 브로커가 실패 할 수 있습니다 "와 개발팀은 적절한 채널을 사용하고 있습니다. "그리고 이것은 정확하게 내가하고있는 일이다.

도움을 주시면 매우 감사하겠습니다.

대단히 감사합니다.

편집 : 그것은 1.10.0

편집으로 업그레이드되었습니다 : 오리온 버전은 1.5.0-다음

편집이다 PS 도끼를 실행 한 후 |

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

편집 : 문제는 주기적으로 발생 GREP contextBroker 나는 다음과 같은 결과가 나타납니다. 사실, 정확히 분마다 발생 :

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

Answer 1

오리온 1.5.0 - 다음은 (12 월 2016 년 발표) (년 10 월 2016 년 출시) 1.5.0과 1.6.0 사이에 실행 버전을 의미합니다. 가장 좋은 경우, 버전은 1 년이며 이는 꽤 많은 시간입니다.

따라서 가장 최근에 출시 된 Orion 버전으로 업그레이드하는 것이 좋습니다 (이 글을 쓰는 순간, 해당 버전은 1.10.0이며, 2017 년 12 월에 출시 됨). 우리는 1.6.0에서 1.10.0 사이의 변화의 델타에서 "오버로깅 (overlogging)"문제를 해결했으며 여러분이 언급 한 것은 그 중 하나 일 수 있습니다.

업그레이드 후에도 문제가 해결되지 않으면 대답에 대한 의견을 말하면 디버깅을 계속합니다.

Answer 2

진단

60 초주기는 구독 (당신의 CLI는 확인 구독 정보 캐시의 다른 설정을 사용하지 않는) 기본 구성 새로 고침 간격을 캐시 정확히이다.

line refered by the log trace in Orion 1.10.0 source code에 상세히 상대 :

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

로그 오차 오리온은의 요소의 일부를 데이터베이스에 가입 컬렉션의 문서에서 CSUB_CONDITIONS 필드 문자열의 배열을 기대하지만 수단 배열 (또는 모두)은 문자열이 아니라 객체 (유형 3은 객체, 즉 BSON specification 세부 정보)입니다.

CSUB_CONDITIONS 상수 corresponds ~ conditions DB의 필드. 이 필드는 Orion 1.3.0에서 변경되었습니다. 1.3 이전.

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

From 1.3.0 on,이 문자열 배열로 단순화되었다 : 0, for instance 1.2.0, 그것은 객체의 배열이었다

"conditions" : [ "temperature" ] 

그래서 내 가설은 그 과거의 어느 순간에 그 오리온 인스턴스 1.33 경계를 넘어서 업데이트되었지만 the procedure to migrate data을 적용하지 않고 (또는 프로 시저를 적용했지만 어떤 방식 으로든 실패했습니다.)

솔루션

당신이 오리온 데이터베이스에서 데이터가 아마도 일관성있는 situtation에있는 점을 감안, 깨끗한 솔루션은 데이터베이스를 제거하는 것입니다. 또는 최소한 csubs 컬렉션입니다.

그러나 이것은 쉽게 삭제할 데이터를 재생성 할 수있는 경우에만 가능합니다. 가능하지 않은 경우 the procedure to migrate data으로 시도 할 수 있습니다. 특히 csub_merge_condvalues.py 스크립트는 다른 잠재적 인 불일치를 해결하기 위해 전체 절차를 적용하는 것이 좋지만 문제를 해결해야합니다.

새 오리온 버전 인을 사용하기 전에 마이 그 레이션 절차가 에 적용되도록 설계되었는지 확인하십시오. 1.3.0 이전의 Orion을 한 번에 1.3.0 이전의 데이터와 함께 사용하여 데이터가 예상치 못한 방식으로 진화 할 수 있으므로 절차를 수정할 수 없었던 것 같습니다. 어쨌든,이 경우에도 절차는 아무 것도없는 것보다 낫습니다.

(-multiservice CLI 매개 변수의 경우 같음) 모든 서비스 별 데이터베이스에 정리/마이그레이션 절차를 적용해야합니다 .