[Backlogmanager] [FIWARE-JIRA] (HELP-8437) [fiware-stackoverflow] Fiware Orion context broker subscription/notification issue

Fermín Galán (JIRA) jira-help-desk at jira.fiware.org
Tue Apr 18 10:12:00 CEST 2017


     [ https://jira.fiware.org/browse/HELP-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fermín Galán resolved HELP-8437.
--------------------------------
    Resolution: Done

> [fiware-stackoverflow] Fiware Orion context broker subscription/notification issue
> ----------------------------------------------------------------------------------
>
>                 Key: HELP-8437
>                 URL: https://jira.fiware.org/browse/HELP-8437
>             Project: Help-Desk
>          Issue Type: Monitor
>          Components: FIWARE-TECH-HELP
>            Reporter: Backlog Manager
>            Assignee: Fermín Galán
>              Labels: broker, fiware, notifications, subscription
>
> Created question in FIWARE Q/A platform on 24-03-2017 at 11:03
> {color: red}Please, ANSWER this question AT{color} http://stackoverflow.com/questions/42997579/fiware-orion-context-broker-subscription-notification-issue
> +Question:+
> Fiware Orion context broker subscription/notification issue
> +Description:+
> I'm using orion context broker GE image orion-psb-image-R5.4 and I registered a device entity  in it , then i implemented in my raspberry pi simple python server script that listens to any incoming message and print it on the Pi's logs . then i sent a subscription message to the context broker to let my raspberry pi subscribe to its corresponding entity in the context broker. The issue is that whenever i update the condition attributes in the entity in the context broker , they're supposed to trigger a notification to the raspberry pi and then the server script in the PI print the notification in the Pi's logs . But what really happens is that the context broker may trigger the notification for once and then stops sending any notification when any additional change is applied to the condition attribute ,  and on every attempt i make i retrieve the subscription status in the context broker and i find that there was a failure stated by the lastfailure attribute giving me the time of my last failed attempt.
> I thought the problem could be the connection to my Pi or even in the server script itself but when i launched direct requests from my terminal  to the raspberry pi , it prints the all messages immediately even when the update is made from a remote place . So i concluded that the problem is definitely with the context broker and the notification process of the subscription  itself .
> Here's the subscription request i made :
> curl -v contextbrokeraddress:1026/v2/subscriptions -s -S --header "Fiware-Service: XYZ" --header "Fiware-ServicePath: /XYZ" --header 'Content-Type: application/json' \
>     -d @- <<EOF
> {
>   "description": " Try",
>   "subject": {
>     "entities": [
>       {
>         "id": "Controller1",
>         "type": "Controller"
>       }
>     ],
>     "condition": {
>       "attrs": [
>         "switch",
>         "datashow"
>       ]
>     }
>   },
>   "notification": {
>     "http": {
>       "url": "http://raspberryPiaddress:8080"
>     },
>     "attrs": [
>      "switch",
>      "datashow"
>     ]
>   },
>   "expires": "2040-01-01T14:00:00.00Z",
>   "throttling": 5
> }
> EOF
> now when the switch attribute is updated with a different value , it may trigger the notification to the raspberry pi for the first time only but then fails on any following attempts.
> this is the simple python script that listens to the incoming notifications and print it in its logs:
> import socket
> HOST, PORT = '', 8080
> listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> listen_socket.bind((HOST, PORT))
> listen_socket.listen(1)
> while True:
>     print "listening on port 8080"
>     client_connection, client_address = listen_socket.accept()
>     print "notified"
>     request = client_connection.recv(1024)
>     print request 
>     client_connection.close()
> And this is how the notification from the context broker is printed on the Pi's logs in its ONLY successful time:
> listening on port 8080
> notified
> POST / HTTP/1.1
> User-Agent: orion/1.7.0 libcurl/7.19.7
> Host: raspberryPiaddress:8080
> fiware-service: XYZ
> Fiware-ServicePath: /XYZ
> X-Auth-Token: token
> Accept: application/json
> Content-length: 208
> Content-type: application/json; charset=utf-8
> Fiware-Correlator: f48ced60-1069-11e7-b743-fa163e7c4daf
> Ngsiv2-AttrsFormat: normalized
> {"subscriptionId":"58cd49191e9c000de6ea89c7","data":[{"id":"Controller1","type":"Controller","switch":{"type":"command","value":"OFF","metadata":{}},"datashow":{"type":"string","value":"OFF","metadata":{}}}]}
> And when the notification is not received on any following updates on the entity , i check that it was failure by retrieving the subscription status which states that a failure happened in the context broker on sending the notification at the exact time of my attempt. This the status i retrieve to check that:
> [
>     {
>         "description": " Try",
>         "expires": "2040-01-01T14:00:00.00Z",
>         "id": "58cd49191e9c000de6ea89c7",
>         "notification": {
>             "attrs": [
>                 "switch",
>                 "datashow"
>             ],
>             "attrsFormat": "normalized",
>             "http": {
>                 "url": "http://ahmadpi.ddns.net:8080"
>             },
>             **"lastFailure": "2017-03-24T08:22:23.00Z",**
>             "lastNotification": "2017-03-24T08:22:18.00Z",
>             "lastSuccess": "2017-03-23T22:09:33.00Z",
>             "timesSent": 66
>         },
>         "status": "failed",
>         "subject": {
>             "condition": {
>                 "attrs": [
>                     "switch",
>                     "datashow"
>                 ]
>             },
>             "entities": [
>                 {
>                     "id": "Controller1",
>                     "type": "Controller"
>                 }
>             ]
>         },
>         "throttling": 5
>     }
> ]
> the problem now seems to be relating to the context broker and the way the subscription/notification processes are handled inside it . Now, i want to know whether the problem regards the context broker  image version that i used or whether it regards something else . I just want to know where's the problem and how it can be handled please and thanks so much. 



--
This message was sent by Atlassian JIRA
(v6.4.1#64016)


More information about the Backlogmanager mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy