could not process input request on the Proton server, the input stream is down due to:invalid stream header: 504F5354 - fiware-orion

I have deployed Proton and a docker image of Orion in the same Ubuntu server.
When Orion is sending events to Proton I'm getting the following failure
PM com.ibm.hrl.proton.server.adapter.eventHandlers.RequestHandler run
INFO: run: could not process input request on the Proton server, the input stream is down due to:invalid stream header: 504F5354
My server is running Ubuntu 14.04, tomcat7 and java 8
And the subscription sent to Orion to get events to Proton is the following
(curl 192.168.90.3:1026/v1/subscribeContext?notifyFormat=xml -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: ct_stc' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "STCSensor",
"isPattern": "false",
"id": "605222424"
}
],
"reference": "http://192.168.90.3:3002/ProtonOnWebServer/rest/events",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"Serial",
"BatteryLevel",
"CurrentRSSI",
"LastPacketRSSI",
"LastPacketSNR",
"OzoneCal"
]
}
],
"throttling": "PT1S"
}
EOF
Adding POST similar to the one received by Proton
POST /test/xml.php HTTP/1.1" 200 168 "-" "orion/0.24.0-next libcurl/7.19.7
<notifyContextRequest>
<subscriptionId>56279a61e4ea5f2df9a9eebc</subscriptionId>
<originator>localhost</originator>
<contextResponseList>
<contextElementResponse>
<contextElement>
<entityId type="STCSensor" isPattern="false">
<id>605222424</id>
</entityId>
<contextAttributeList>
<contextAttribute>
<name>Altitude</name>
<type>integer</type>
<contextValue>720</contextValue>
</contextAttribute>
...
And logs in Orion
orion_1 | INFO#14:40:04 httpRequestSend.cpp[199]: Starting transaction to 192.168.90.3:3002/ProtonOnWebServer/rest/events
orion_1 | INFO#14:40:04 connectionOperations.cpp[307]: Database Operation Successful (insert: { _id: ObjectId('5627a3c4e4ea5f2df9a9eebe'), expiration: 1448030404, reference: "http://192.168.90.3:3002/ProtonOnWebServer/rest/events", throttling: 1, servicePath: "/#", entities: [ { id: "705222424", type: "STCSensor", isPattern: "false" } ], attrs: [], conditions: [ { type: "ONCHANGE", value: [ "Serial", "BatteryLevel", "CurrentRSSI", "LastPacketRSSI", "LastPacketSNR"] } ], lastNotification: 1445438404, count: 1, format: "XML" })
orion_1 | INFO#14:40:04 rest.cpp[467]: Transaction ended
orion_1 | WARNING#14:40:04 httpRequestSend.cpp[435]: Notification failure for 192.168.90.3:3002 (curl_easy_perform failed: Failure when receiving data from the peer)
orion_1 | INFO#14:40:04 httpRequestSend.cpp[452]: Transaction ended
Is anything wrong in the subscription?
Thanks for your help

Related

Cannot Post Hyperledger Transaction on Rest API

I am having some trouble posting a transaction on my ReST server. When I try to POST a transaction, I always get a 422 error. If I delete any fields, I will get a 500 error. It seems like whatever transaction id is there is invalid, and I do not know why it is invalid. In my original .cto files, I did not ask for there to be a transactionID field, so I am assuming this is a default field. Here is a screenshot of my POST method:
Here is my input that I put in:
{
"$class": "models.transactionsModel.InvalidateCertificate",
"certificate": "#cert2",
"transactionId": "string",
"timestamp": "2018-06-18T16:57:45.644Z"
}
I made the certificate identifiable by a hash string
Here is the resulting curl, body, and header respectively,
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ \
"$class": "models.transactionsModel.InvalidateCertificate", \
"certificate": "#cert2", \
"transactionId": "string", \
"timestamp": "2018-06-18T16:57:45.644Z" \
}' 'http://localhost:3000/api/models.transactionsModel.InvalidateCertificate'
{
"error": {
"statusCode": 422,
"name": "ValidationError",
"message": "The `models_transactionsModel_InvalidateCertificate` instance is not valid. Details: `transactionId` can't be set (value: \"string\").",
"details": {
"context": "models_transactionsModel_InvalidateCertificate",
"codes": {
"transactionId": [
"absence"
]
},
"messages": {
"transactionId": [
"can't be set"
]
}
},
"stack": "ValidationError: The `models_transactionsModel_InvalidateCertificate` instance is not valid. Details: `transactionId` can't be set (value: \"string\").\n at /Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/dao.js:398:12\n at models_transactionsModel_InvalidateCertificate.<anonymous> (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/validations.js:578:11)\n at models_transactionsModel_InvalidateCertificate.next (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/hooks.js:93:12)\n at models_transactionsModel_InvalidateCertificate.<anonymous> (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/validations.js:575:23)\n at models_transactionsModel_InvalidateCertificate.trigger (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/hooks.js:83:12)\n at models_transactionsModel_InvalidateCertificate.Validatable.isValid (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/validations.js:541:8)\n at /Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/dao.js:394:9\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at Function.ObserverMixin._notifyBaseObservers (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:178:5)\n at Function.ObserverMixin.notifyObserversOf (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)\n at Function.ObserverMixin._notifyBaseObservers (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)\n at Function.ObserverMixin.notifyObserversOf (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)\n at Function.ObserverMixin._notifyBaseObservers (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)"
}
}
{
"date": "Mon, 18 Jun 2018 18:23:47 GMT",
"content-encoding": "gzip",
"x-content-type-options": "nosniff",
"x-download-options": "noopen",
"x-frame-options": "DENY",
"content-type": "application/json; charset=utf-8",
"access-control-allow-origin": "http://localhost:3000",
"transfer-encoding": "chunked",
"connection": "keep-alive",
"access-control-allow-credentials": "true",
"vary": "Origin, Accept-Encoding",
"x-xss-protection": "1; mode=block"
}
What is even stranger is that I can submit a valid transaction via the Composer playground. In the composer playground, though, it does not ask for a transactionID or timestamp - it automatically generates while the transaction is being submitted.
See the answer here -> error executing hyperledger fabric code on localhost:3000 (through REST) - transactionId - it is really a Loopback issue.
Post your same transaction as follows (but remove the transactionId and timestamp - these are generated for you and the former represents the transaction Id on the ledger):
{
"$class": "models.transactionsModel.InvalidateCertificate",
"certificate": "#cert2"
}
cheers

Orion Context Broker - Subscriptions only notify the first 20 entities

Using this script:
#!/bin/bash
(curl http://orionip:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' --header 'fiware-service: service' --header 'fiware-servicepath: /servicepath' \
-d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Sensor",
"isPattern": "true",
"id": "Parquimetro:.*"
}
],
"attributes": [
"recaudacion"
],
"reference": "http://cometip:80/notify",
"duration": "P4Y",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"recaudacion", "numeroTiques"
]
}
],
"throttling": "PT24H"
}
EOF
Makes a subscription for 170 entities (Parquimetro:1, Parquimetro:2, Parquimetro:3, ..., Parquimetro:170) to notify Comet for storing historical data, but only the first 20 entities got notified. I need it to notify all entities (which are right now 170, not 20).
Using /v1/subscribeContext?limit=200 doesn't help either.
Any idea?
There is an open issue at Orion github about it from time ago.
Currently Orion behaves that way, but there is a workaround in place: do a (paginated) query to get all entities just before doing the subscription. It could happen some "race condition" if some update arrives since the query and the subscription, but, depending on the use case, it may suffice.

unmarshalling error in hyperledger's REST API?

I sent this request to hyperledger's REST API:
$ curl -X POST --header "Content-Type: application/json" -d '{ "jsonrpc": "2.0", "method": "deploy", "params": { "type": 1, "chaincodeID":{ "path":"github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" }, "ctorMsg": { "args":["init", "a", "1000", "b", "2000"] } }, "id": 1 }' localhost:7050/chaincode
and this is the error message I got in return:
{"jsonrpc":"2.0","error":{"code":-32700,"message":"Parse error","data":"Error unmarshalling chaincode request payload: illegal base64 data at input byte 0"},"id":null}
I then added debug log in rest_api.go to check whatever is received by the peer
and got this log:
16:03:46.323 [rest] ProcessChaincode -> DEBU 027 reqBody = { "jsonrpc": "2.0", "method": "deploy", "params": { "type": 1, "chaincodeID":{ "path":"github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02" }, "ctorMsg": { "args":["init", "a", "1000", "b", "2000"] } }, "id": 1 }
16:03:46.331 [rest] ProcessChaincode -> ERRO 028 Error unmarshalling chaincode request payload: illegal base64 data at input byte 0
The received message seems to match with the definition of "rpcRequest", "ChaincodeSpec", and "ChaincodeInput", I don't understand why it keeps throwing unmarshalling error to me...

No Notification from Orion Context Broker

I am working with the Orion Context Broker and wanna get notifications for the following subscription, added to orion.lab.fiware.org:1026:
curl -v orion.lab.fiware.org:1026/v2/subscriptions -X POST -s -S --header 'Content-Type: application/json' --header "X-Auth-Token: <myToken>" -d #- <<EOF
{
"description": "A subscription to get info about Room1",
"subject": {
"entities": [
{
"id": "11582",
"type": "User"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"http": {
"url": "http://<myIPAddress>:8080"
},
"attrs": [
"temperature"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
myToken: the token generated by the FIWARE server
myIPAddress: the IP address of my PC
However, in my sample HTTP server program (Node.js) on port 8080 I do not receive any notifications. I should note that after adding the above subscription, I add the entity with id 11582 through another POST request to orion.lab.fiware.org:1026/v2/entities.
When I read later the added subscription, it confirms that the notification has been sent (through lastNotification):
{
"id": "5768088c70dce43aa351cf9b",
"description": "A subscription to get info about Room1",
"expires": "2040-01-01T14:00:00.00Z",
"status": "active",
"subject": {
"entities": [
{
"id": "11582",
"idPattern": "",
"type": "User"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"timesSent": 1,
"lastNotification": "2016-06-20T15:16:04.00Z",
"attrs": [
"temperature"
],
"attrsFormat": "normalized",
"http": {
"url": "http://<myIPAddress>:8080"
}
},
"throttling": 5
}
Any idea why I do not receive the notification i my HTTP server program? My firewall is also off.
Thanks!
The following test has been donde in orion.lab.fiware.org. The termina1l.txt file shows the subscriptions and entity creation request sent to Orion (note we use localhost:10026, as the test has been done in the orion.lab.fiware.org host itself) and terminal2.txt file shows the notification received at the listener process (nc).
We have also done the same test (using UserTest2 type this time) running the listener on a VM machine at FIWARE Lab (which IP cannot be disclosed for security reasons) with the 1028 port openend in the Security Group and everything worked fine again, getting:
POST / HTTP/1.1
user-agent: orion/1.2.1 libcurl/7.19.7
host: 130.206.112.29:1028
accept: application/json
content-length: 146
content-type: application/json; charset=utf-8
fiware-correlator: 0870b41c-378d-11e6-910f-52540003a38e
ngsiv2-attrsformat: normalized
X-Forwarded-For: 127.0.0.1
Connection: keep-alive
{"subscriptionId":"5768ff6a70dce43aa351cfaa","data":[{"id":"11582","type":"UserTest2","temperature":{"type":"Float","value":23.5,"metadata":{}}}]}
Thus, I understand that something between orion.lab.fiware.org and your process is blocking the traffic. Note that apart for the firewall running in your machine (which you mention is off) another firewall layer could be blocking (e.g. FIWARE cloud or AWS cloud security group, coorporate firewalls, etc.)

Doubts about notifications format in Orion usin APIv2

we are testing the subscription functionality using the APIv2. We are following the guidelines described in http://telefonicaid.github.io/fiware-orion/api/v2/ . We are able to create a correct subscription but the format of the notification messages that we received is not what we expected. The format of these messages is like the APIv1 version. Is this the expected behavior?
We are using the Docker image from https://hub.docker.com/r/fiware/orion/.
Version information about the build:
{
"orion" : {
"version" : "1.0.0-next",
"uptime" : "0 d, 1 h, 28 m, 47 s",
"git_hash" : "a729812c45d2749fffbc19add17631b2fffc8797",
"compile_time" : "Fri Apr 8 10:05:55 UTC 2016",
"compiled_by" : "root",
"compiled_in" : "838a42ae8431"
}
}
Steps to reproduce:
Create an entity:
(curl -X POST http://<cb_url>:<cb_port>/v2/entities?options=keyValues -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"type":"Room",
"id": "test",
"humidity":40
}
EOF
Create a subscription:
(curl -X POST http://<cb_url>:<cb_port>/v2/subscriptions -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"description": "One subscription to rule them all",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Room"
}
],
"condition": {
"attributes": [
"humidity"
],
"expression": {
"q": "humidity>40"
}
}
},
"notification": {
"callback": "http://192.168.99.1:5000",
"attributes": [
"humidity"
],
"throttling": 5
},
"expires": "2016-05-05T14:00:00.00Z"
}
EOF
Update attribute.:
(curl -X PUT <cb_url>:<cb_port>/v2/entities/test/attrs/humidity/value -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"value": 50
}
EOF
We get the notification with the following format:
{u'contextResponses': [
{u'contextElement': {
u'attributes': [{
u'name': u'humidity',
u'type': u'none',
u'value': {u'value': 50}
}],
u'id': u'test',
u'isPattern': u'false',
u'type': u'Room'
},
u'statusCode': {
u'code': u'200',
u'reasonPhrase': u'OK'
}}],
u'originator': u'localhost',
u'subscriptionId': u'5707b72882fc213130f4e5b9'}
NGSIv2 notification formats have not been yet implemented (at Orion 1.0.0). Note that NGSIv2 is yet in beta status and sometimes the specification (where the new notification format has been defined) is a step forward the implementation.
There is a github issue about this, to which you can subscribe in order to know when this feature gets implemented.
EDIT: NGSIv2 notification formats have been implemented in Orion 1.1.0.