TNO / knowledge-engine

Improves interoperability between systems (i.e. devices, platforms, apps, databases) by exchanging data based on their semantics
https://knowledge-engine.eu
Apache License 2.0
33 stars 4 forks source link

Reponse to REACT interaction via /sc/handle is not received by POST service #264

Closed Sophietje closed 10 months ago

Sophietje commented 3 years ago

In GitLab by @jarne.kerkaert.inetum-realdolmen.world on Jul 25, 2021, 18:45

Sometimes, when a SSA reacts to a POST interaction via POST /sc/handle, the poster does not receive the response (it keeps polling). I have only experienced this using the cloud KE.

Switching to a local instance has always solved this problem. Usually, after a couple of days, the problem also disappears on the cloud instance (probably because of a restart).

As implied above, the reacter receives message successfully, and also correctly responds. Therefore I assume that the problem is with KE.

This is the POST interaction:

[
    {
        "knowledgeInteractionId": "http://interconnect.eu/partner/interaction/ec4d53b9-a83f-4f15-9e8c-e79b45a592d0",
        "knowledgeInteractionType": "PostKnowledgeInteraction",
        "communicativeAct": {
            "requiredPurposes": [
                "https://www.tno.nl/energy/ontology/interconnect#InformPurpose"
            ],
            "satisfiedPurposes": [
                "https://www.tno.nl/energy/ontology/interconnect#InformPurpose"
            ]
        },
        "graphPattern": null,
        "argumentGraphPattern": "?device_uri <https://saref.etsi.org/core/makesMeasurement> <http://inetum.world/demandresponse/measurement#measurement> . ?device_uri <https://saref.etsi.org/core/hasState> <http://inetum.world/demandresponse/appliance#state> . <http://inetum.world/demandresponse/appliance#state> a ?state_type . <http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/relatesToProperty> <http://inetum.world/demandresponse/property#property> . <http://inetum.world/demandresponse/property#property> a <https://saref.etsi.org/core/Power> . <http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/hasValue> ?value . <http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/isMeasuredIn> <http://www.ontology-of-units-of-measure.org/resource/om-2/watt> .<http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/hasTimestamp> ?timestamp . ",
        "resultGraphPattern": null
    }
]

This is the registered REACT interaction:

[
    {
        "knowledgeInteractionId": "https://world.inetum.dr/adapter/reactive/interaction/04bb0a95-ebba-4282-a90a-b6cf67e15640",
        "knowledgeInteractionType": "ReactKnowledgeInteraction",
        "communicativeAct": {
            "requiredPurposes": [
                "https://www.tno.nl/energy/ontology/interconnect#InformPurpose"
            ],
            "satisfiedPurposes": [
                "https://www.tno.nl/energy/ontology/interconnect#InformPurpose"
            ]
        },
        "graphPattern": null,
        "argumentGraphPattern": "?device_uri <https://saref.etsi.org/core/makesMeasurement> <http://inetum.world/demandresponse/measurement#measurement> . ?device_uri <https://saref.etsi.org/core/hasState> <http://inetum.world/demandresponse/appliance#state> . <http://inetum.world/demandresponse/appliance#state> a ?state_type . <http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/relatesToProperty> <http://inetum.world/demandresponse/property#property> . <http://inetum.world/demandresponse/property#property> a <https://saref.etsi.org/core/Power> . <http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/hasValue> ?value . <http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/isMeasuredIn> <http://www.ontology-of-units-of-measure.org/resource/om-2/watt> .<http://inetum.world/demandresponse/measurement#measurement> <https://saref.etsi.org/core/hasTimestamp> ?timestamp . ",
        "resultGraphPattern": null
    }
]

This is the body of the POST request (ignore the variables):

[
    {
        "device_uri": "<http://inetum.world/demandresponse/appliance#{{$randomUUID}}>",
        "state_type": "<https://saref.etsi.org/core/OnState>",
        "value": "'{{$randomInt}}.00'^^xsd:float",
        "timestamp": "'{{$isoTimestamp}}'^^xsd:dateTime"
    }
]
Sophietje commented 3 years ago

In GitLab by @han.kruiger.tno.nl on Jul 26, 2021, 07:28

When this bug occurs, is it soon after the knowledge bases were registered? Or have they been around for a while (~a few seconds) when this occurs?

If it happens quickly after registration of the knowledge base(s), I suspect it may be related to #247.

Sophietje commented 3 years ago

In GitLab by @jarne.kerkaert.inetum-realdolmen.world on Jul 26, 2021, 07:45

Hi @han.kruiger.tno.nl , if I remember correctly, this has always happened after the KB's had been registered for a while. Simply recreating them does not fix the problem, the only thing that has worked (to my knowledge) is restarting the entire KE.

Sophietje commented 3 years ago

In GitLab by @remi.roche.tiko.energy on Aug 19, 2021, 11:34

I created a new issue to document that it is still happening. https://gitlab.inesctec.pt/interconnect/knowledge-engine/-/issues/268

Sophietje commented 3 years ago

In GitLab by @barry.nouwt.tno.nl on Sep 17, 2021, 08:07

Hi @jarne.kerkaert.inetum-realdolmen.world,

we have found the cause of similar behavior reported in issue #268. It was caused by another reactive knowledge interaction that was not responding. The Knowledge Engine sequentially (order undefined) contacts the Knowledge Bases with matching interactions and only continues to the next after a valid response. This means that if there are two KBs with a matching interaction and one of them does not respond when the KE contacts them, the behavior you describe can happen. This also happens more often in the cloud version, because there are more KBs in general and partners might not always clean up their KB when finished testing.

Do you still experience this problem? If so, could you provide the current Knowledge Base Ids and Knowledge Interaction Ids involved (we've deployed a new version after this issue was reported), so we can take a look if the above is the case.

Best regards, Barry

Sophietje commented 3 years ago

In GitLab by @jarne.kerkaert.inetum-realdolmen.world on Sep 20, 2021, 07:56

@barry.nouwt.tno.nl Thanks! Just to see if I understand correctly, the scenario should be the following:

I will switch back to the cloud instance for testing and get back to you if the problem still occurs.

Sophietje commented 3 years ago

In GitLab by @jarne.kerkaert.inetum-realdolmen.world on Sep 21, 2021, 11:23

@barry.nouwt.tno.nl The issue was indeed the one you described. One of our partners had deployed their own mock service for one of our deployed services.

I am closing this issue.