-
Notifications
You must be signed in to change notification settings - Fork 21
Incorrect processing for notification about changes in multiple context entities. #73
Comments
Clearly, Fiware-Cepheus CEP does not handle this case where the This needs an evolution of the current code to be supported. For reference, https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/user/service_path.md is the documentation of the Orion description of the service path, clearly Fiware-Cepheus is missing some edge cases. |
[Steps] I followed the given below procedure for Reproducing this issue : • Verified the Creation of entity in Orion by displaying the entities in its database as shown below: Therefore, the creation of entity in Orion has been successful. • Now, I POST’ed my config.json in Cepheus file as follows : { [Result] [Observation] After observing and investigating the logs, we find that the Communication between both, Fiware Cepheus and Orion works well for (id : “.*”) as we receive the notifycontext request whenever we change/updateContext in any of (Room1,Room2,Lab3) as shown in the logs of Cepheus as above. Similarly,I subscribed for only Single entity Room1 (id:Room1) from Cepheus and whenever I update the value in Room1 at fiware-orion,I subsequently receive the notifyContext request on Cepheus. [Confirmation] |
Hi @marcc-orange sir , @efviodo |
I am not able to reproduce this issue. Cepheus-CEP is working as expected. I followed the steps:
Observations:
Please verify if my above understanding is correct or I missed something from the reported issue. |
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:
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.
The text was updated successfully, but these errors were encountered: