Брокер контекста Orion - запрос по местоположению без элементов

Я работаю с Orion Context Broker версии 0.25.0.

Если я загружаю брокер контекста только контекстными сущностями и ищу сущности в определенной области, все, кажется, работает нормально:

(curl localhost:1026/v1/queryContext?limit=100 -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d  @- | python -mjson.tool) <<EOF
{
    "entities":[
        {
            "type":"Dispositivo_tmp",
            "isPattern":"true",
            "id":".*"
        }
    ],
    "restriction": {
        "scopes": [
            {
                "type": "FIWARE::Location",
                "value": {
                    "circle": {
                        "centerLatitude": "43.322361",
                        "centerLongitude": "-1.983222",
                        "radius": "1500"
                    }
                }
            }
        ]
    }
}
EOF

Я получаю ответ с объектами контекста, расположенными в этой области:

...
{
            "contextElement": {
                "attributes": [
                    {
                        "metadatas": [
                            {
                                "name": "location",
                                "type": "string",
                                "value": "WGS84"
                            }
                        ],
                        "name": "position",
                        "type": "coords",
                        "value": "43.3221, -1.9831"
                    },
                    {
                        "name": "pressure",
                        "type": "integer",
                        "value": "1"
                    },
                    {
                        "name": "temperature",
                        "type": "float",
                        "value": "25"
                    }
                ],
                "id": "CE_5.1",
                "isPattern": "false",
                "type": "Dispositivo_tmp"
            },
            "statusCode": {
                "code": "200",
                "reasonPhrase": "OK"
            }
        }
    ]
}

И если в указанной области нет элементов, я получаю ожидаемый ответ:

{
    "errorCode": {
        "code": "404",
        "reasonPhrase": "No context element found"
    }
}

Проблема возникает, если я загружаю брокер контекста также с регистрациями контекста. Если у меня есть как сущности контекста, так и регистрации контекста в брокере контекста, и я проверяю сущности контекста в области, которая, как мне известно, пуста, я не получу никакого ответа или получу этот:

{
    "errorCode": {
        "code": "200",
        "reasonPhrase": "OK"
    }
}

И кажется, что чем больше количество контекстных регистраций, загруженных в брокер контекста, тем больше времени требуется для получения (отрицательного) ответа от системы.

В том же сценарии нет проблем, если я ищу сущности контекста в области с элементами. В этом случае я получу правильный ответ.

Есть ли во всем этом смысл?

Спасибо


fiware fiware-orion
person Julen    schedule 05.01.2016    source источник
comment
Я понимаю, что часть под EDIT - это фактический ответ на вопрос. Таким образом, я бы предложил вырезать и вставить его в правильный ответ ниже (StackOverflow позволяет самостоятельно отвечать на вопросы). Спасибо!   -  person fgalan    schedule 05.01.2016
comment
Также для ясности включите пример неправильного URL и правильного. Это было бы прекрасно!   -  person LeandroGuillen    schedule 05.01.2016

Ответы (1)


arrow_upward
1
arrow_downward

Я видел, что такое поведение связано с URL-адресом, который я определил при создании контекстных регистраций.

URL неверный. Поэтому, когда брокер контекста пытается связаться с устройством, используя предоставленный URL-адрес, он начинает ждать ответа, который не приходит.

Я изменил URL-адрес и вместо этого использовал фиктивный тестовый сервер "create-server.py ":

http://localhost:1028/accumulate

Используя его, брокер контекста получает немедленный ответ и продолжает выполнение.

person Julen    schedule 07.01.2016