Subscription status change after post

Question

After successfully installed Cygnus connector and testing the creation of subscriptions.

With bellow files:

agent_1.conf

cygnus-ngsi.sources = http-source
cygnus-ngsi.sinks = hdfs-sink
cygnus-ngsi.channels = hdfs-channel

cygnus-ngsi.sources.http-source.type = org.apache.flume.source.http.HTTPSource
cygnus-ngsi.sources.http-source.channels = hdfs-channel
cygnus-ngsi.sources.http-source.port = 5050
cygnus-ngsi.sources.http-source.handler = com.telefonica.iot.cygnus.handlers.NGSIRestHandler
cygnus-ngsi.sources.http-source.handler.notification_target = /notify
cygnus-ngsi.sources.http-source.handler.default_service = [ PERSONALIZED SERVICE NAME ]
cygnus-ngsi.sources.http-source.handler.default_service_path = /[ PERSONAL SERVICE PATH ]
cygnus-ngsi.sources.http-source.handler.events_ttl = 10
cygnus-ngsi.sources.http-source.interceptors = ts gi
cygnus-ngsi.sources.http-source.interceptors.ts.type = timestamp
cygnus-ngsi.sources.http-source.interceptors.gi.type = com.telefonica.iot.cygnus.interceptors.NGSIGroupingInterceptor$Builder
cygnus-ngsi.sources.http-source.interceptors.gi.grouping_rules_conf_file = /usr/cygnus/conf/grouping_rules.conf

cygnus-ngsi.sinks.hdfs-sink.type = com.telefonica.iot.cygnus.sinks.NGSIHDFSSink
cygnus-ngsi.sinks.hdfs-sink.channel = hdfs-channel
cygnus-ngsi.sinks.hdfs-sink.hdfs_host = storage.cosmos.lab.fiware.org
cygnus-ngsi.sinks.hdfs-sink.hdfs_port = 14000
cygnus-ngsi.sinks.hdfs-sink.hdfs_username = [ MY USERNAME ]
cygnus-ngsi.sinks.hdfs-sink.oauth2_token = [ MY TOKEN ]


cygnus-ngsi.channels.hdfs-channel.type = com.telefonica.iot.cygnus.channels.CygnusMemoryChannel
cygnus-ngsi.channels.hdfs-channel.capacity = 1000
cygnus-ngsi.channels.hdfs-channel.transactionCapacity = 100

cygnus_interface_1.conf

CYGNUS_USER=cygnus
CONFIG_FOLDER=/usr/cygnus/conf
CONFIG_FILE=/usr/cygnus/conf/agent_1.conf
AGENT_NAME=cygnus-ngsi
LOGFILE_NAME=cygnus.log
ADMIN_PORT=8081
POLLING_INTERVAL=30

TESTING WITH NGSI V1

I have tried creating a subscription as presented below:

[ POST ]

http://[ MY ORION IP ]:1026/v1/subscribeContext

[ HEADER ]

Content-Type:application/json
Accept: application/json
Fiware-Service: [ PERSONALIZED SERVICE NAME ]
Fiware-ServicePath: /[ PERSONALIZED PATH ]

[ BODY ]

{
    "entities": [
        {
            "type": "PhysicalTest",
            "isPattern": "false",
            "id": "TEMPORAL"
        }
    ],
    "attributes": [
        "test"
    ],
    "reference": "http://localhost:5050/notify",
    "duration": "P1M",
    "notifyConditions": [
        {
            "type": "ONCHANGE",
            "condValues": [
                "test"
            ]
        }
    ],
    "throttling": "PT1S"
}

TESTING WITH NGSI V2

I also have tried creating a subscription as presented below:

[ POST ]

http://[ MY ORION IP ]:1026/v2/subscriptions

[ HEADER ]

Content-Type:application/json
Accept: application/json
Fiware-Service: [ PERSONALIZED SERVICE NAME ]
Fiware-ServicePath: /[ PERSONALIZED PATH ]

[ BODY ]

{
  "description": "Subscription to store physical tests",
  "subject": {
    "entities": [
      {
        "type": "PhysicalTest",
        "isPattern": "false",
        "id": "TEMPORAL"
      }
    ],
    "condition": {
      "attrs": [
        "test"
      ],
      "expression": {
        "q": "test!=0"
      }
    }
  },
  "notification": {
    "http": {
      "url": "http://localhost:5050/notify"
    },
    "attrs": [
      "test"
    ]
  },
  "expires": "2018-04-05T14:00:00.00Z",
  "throttling": 5
}

When checking previously created subscription. I found it with: "status": "active"; which is great.

THE POST

In both type of subscriptions (i.e., through v1 and v2) I post as showed below:

[ POST ]

http://[ MY ORION IP ]:1026/v2/entities

[ HEADER ]

Content-Type:application/json
Accept: application/json
Fiware-Service: [ PERSONALIZED SERVICE NAME ]
Fiware-ServicePath: /[ PERSONALIZED PATH ]

[ BODY ]

{
    "id": "TEMPORAL",
    "type": "PhysicalTest",
    "test": {
        "value": "Timed Up and Go",
        "type": "test-type"
        },
    "sensor": {
        "value": "Accelerometer",
        "type": "sensor-type",
        "metadata": {
            "speed": {
                "value": "80",
                "type": "hz"
                }
            }
        },
    "data": {
        "value": "0.0635477304458618,0.00490868091583252,0.0516815185546875,2016-09-08T10:51:41.341Z-0500",
        "type": "sensor-data"
        }
}

THE FAIL RESULT

The status of my subscriptions in both cases turn to: "status": "failed"

Moreover, there is no evidence of that Cosmos is storing anything while looking at the directories where entity files should be stored:

curl -X GET "http://storage.cosmos.lab.fiware.org:14000/webhdfs/v1/user/[ MY USERNAME ]?op=liststatus&user.name=[ MY USERNAME ]" -H "X-Auth-Token: [ MY TOKEN ]" | python -m json.tool

JUST FOR THE RECORD

I have already successfully tested the Cygnus connection by:

./notification-json-simple.sh http://localhost:5050/notify

Thus, I presume they might be something with my subscription mechanism, but still cannot find the glitch.

ORION LOG retrieved FROM /tmp/ContextBroker.log

.
.
.
time=Sunday 29 Jan 19:41:07 2017.697Z | lvl=WARN | corr=N/A | trans=1485717075-957-00000000006 | from=pending | srv=pending | subsrv=pending | comp=Orion | op=AlarmManager.cpp[328]:notificationError | msg=Raising alarm NotificationError localhost:5050/notify: (curl_easy_perform failed: Couldn't connect to server)

Any hint to solve this?

Two guesses: first, do you try specifying the entity id in the subscription creation (not using "idPattern")? You can test something like this: `"entities": [ { "id": "ypioca", "type": "room" } ],` Second, try to create the subscription with /v1 instead of /v2. I had this problem with STH Comet: seems to work with /v1 api. — Dalton Cézane, Jan 28 '17 at 21:44
I deleted previous comment because I was wrongly testing. My last try was by setting "idPattern": "false", and my subscription still active now :). But, still cannot retrieve any that is suppose to be storing on Cosmos, how do you do that? — netzahdzc, Jan 28 '17 at 22:12
Did you try registering subscriptions with `/v1/subscribeContext` instead of `/v2/subscriptions` as I told? And putting the entity id? Also, I think where you put "idPattern" is "isPattern". — Dalton Cézane, Jan 28 '17 at 22:16
I tried with v1/subscribeContext same behaviour as before, "status": "active" but after posting it turns to "status": "failed" — netzahdzc, Jan 28 '17 at 23:06
I edited the post with both mechanism v1 and v2 I'm using for the subscription, without success — netzahdzc, Jan 29 '17 at 00:00
When "status" changes to "failed" it typically means that notification delivery had some problem. The ContextBroker log could provide information about it. Could you have a look to that file (typically at `/var/log/contextBroker/contextBroker.log in conventional installation), pls? — fgalan, Jan 29 '17 at 11:48
thanks for replying @fgalan I edited the question with today's orion log, which by the way I retrieve from docker; since I'm running Orion as a container. — netzahdzc, Jan 29 '17 at 16:27
would this error give any insight: time=Sunday 29 Jan 19:41:07 2017.697Z | lvl=WARN | corr=N/A | trans=1485717075-957-00000000006 | from=pending | srv=pending | subsrv=pending | comp=Orion | op=AlarmManager.cpp[328]:notificationError | msg=Raising alarm NotificationError localhost:5050/notify: (curl_easy_perform failed: Couldn't connect to server) — netzahdzc, Jan 29 '17 at 20:07
Yes, that error is the key to discover the problem... However, I din't see it after the question post in the section "ORION LOG retrieved FROM /tmp/ContextBroker.log"... Maybe that section should be edited, so it includes just the above log error (this way it would be clear if some other user gets into this question) — fgalan, Jan 30 '17 at 11:19

netzahdzc · Accepted Answer · 2017-01-30T04:34:56.557

2

Apparently everything was about the notification reference. By changing localhost for respective IP address, my subscription keeps alive (i.e., keeping "status": "active") after any post. I have also tested notifying/triggering a notification from Orion to a third party server successfully as well as Cosmos.

edited Jan 30 '17 at 04:34

answered Jan 29 '17 at 23:31

netzahdzc

237
1
10

1

It makes sense... note that when Orion runs inside docker, "localhost" means "Orion docker container itself". I guess that Cygnus was running externaly (either in a separate container in the same host or in a the host istelf) so you need to use the IP in that case, as you correctly explain in your self-answer. – fgalan Jan 30 '17 at 11:17

Subscription status change after post

TESTING WITH NGSI V1

TESTING WITH NGSI V2

THE POST

THE FAIL RESULT

JUST FOR THE RECORD

ORION LOG retrieved FROM /tmp/ContextBroker.log

1 Answers1

Linked