-
Notifications
You must be signed in to change notification settings - Fork 21
Incorrect processing for notification about changes in multiple context entities. #73
Description
Experimenting with Orion and Cepheus I discovered that if a cepheus configuration is used for an EventIn that refers to a particular context entity, everything works as expected.
"in": [ { "host":"http://localhost:8080", "in":[ { "id":"Room1", "type":"Room", "attributes":[ { "name":"temperature", "type":"double" }, { "name":"floor", "type":"string" } ], ... }
How ever If I define a generic EventIn for all rooms, then the Cepheus behaves unexpectedly. When configuring the cepheus with such a configuration and despite having well-defined rules, no exit event is recorded and no errors appear in the logfile. This is rare since Cepheus generates a subscription for each EventIn that is defined in the configuration file. When creating the subscription in Orion, it should notify the cepheus by means of a request, sending all the contexts that meet the criteria of this subscription.
"in": [ { "host":"http://localhost:8080", "in":[ { "id":".*", "type":"Room", "isPattern": true, "attributes":[ { "name":"temperature", "type":"double" }, { "name":"floor", "type":"string" } ], ... }
Perhaps the cepheus is not ready to receive a notifyContext request where changes to multiple context entities are notified.
I did not mention it, I have three different rooms in my Orion context broker: Room1, Room2 and Room3. When the subscription is created in Orion, the three context entities are notified. Finally my application has the Fiware-ServicePath: /hotel.
I did some dubugging using the Fiware accumulator-server.py and then I got the following notifyContext request:
POST http://172.17.0.1:1028/accumulate
Fiware-Servicepath: /hotel,/hotel,/hotel
Content-Length: 1551
User-Agent: orion/1.7.0-next libcurl/7.19.7
Host: 172.17.0.1:1028
Accept: application/json
Fiware-Service: sheraton
Content-Type: application/json; charset=utf-8
Fiware-Correlator: b5324fd4-7f8f-11e8-b121-0242ac110003
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "pressure",
"type": "Integer",
"value": 720
},
{
"name": "temperature",
"type": "Float",
"value": 23
}
],
"id": "Room1",
"isPattern": "false",
"type": "Room"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
},
{
"contextElement": {
"attributes": [
{
"name": "pressure",
"type": "Integer",
"value": 700
},
{
"name": "temperature",
"type": "Float",
"value": 21
}
],
"id": "Room2",
"isPattern": "false",
"type": "Room"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
},
{
"contextElement": {
"attributes": [
{
"name": "pressure",
"type": "Integer",
"value": 740
},
{
"name": "temperature",
"type": "Float",
"value": 18
}
],
"id": "Room3",
"isPattern": "false",
"type": "Room"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
],
"originator": "localhost",
"subscriptionId": "5b3cce1faa7643a55888eb77"
}
Is it possible that the cepheus is not doing anything when receiving the request, because of the value of the header it brings? Look at the value that the accumulator-server saved in the log file:
/hotel, /hotel, /hotel
It would seem that Orion concatenated the Fiware-ServicePath of each context that met the criteria of the subscription. So, since the Cepheus configuration has a value other than Fiware-ServicePath ("/ hotel"), nothing happens.