We are using Idas/Orion/Mongo(docker build) and Cygnus together in order to send data to Ckan and Cosmos.
We simulated 100 sensors that send data each 3 minutes, This approach stopped working after 2 days, I've checked both IDAS and Orion logs and see these Mongodb erros in the logs, there is not any notification coming both of the components no more.
Idas log:
failed time=2016-05-25T11:30:13,852.191UTC | lvl=ERROR | comp=iota:Manager | op=checkIndexes | file=[140414053451808:admin_service.cc:148] | msg=Check configuration, error in checkIndexes DBException can't connect couldn't connect to server 172.17.0.2:27017 (172.17.0.2), connection attempt failed
time=2016-05-25T11:30:13,853.966UTC | lvl=ERROR | comp=iota:Manager | op=conn | file=[140414053451808:mongo_connection.cc:254] | msg=It has reached the maximum mongo pool
time=2016-05-25T11:30:13,853.993UTC | lvl=ERROR | comp=iota:Manager | op=conn | file=[140414053451808:mongo_connection.cc:258] | msg=create a new con
Orion log:
time=2016-05-25T11:30:04.948UTC | lvl=INFO | trans=N/A | srv=N/A | subsrv=N/A | from=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1719]: Orion Context Broker is running
time=2016-05-25T11:30:04.964UTC | lvl=ERROR | trans=N/A | srv=N/A | subsrv=N/A | from=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[140]: Database Startup Error (cannot connect to mongo - doing 100 retries with a 1000 microsecond interval)
time=2016-05-25T11:30:05.969UTC | lvl=INFO | trans=N/A | srv=N/A | subsrv=N/A | from=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[205]: Successful connection to database
time=2016-05-25T11:30:05.970UTC | lvl=INFO | trans=N/A | srv=N/A | subsrv=N/A | from=N/A | function=setWriteConcern | comp=Orion | msg=connectionOperations.cpp[681]: Database Operation Successful (setWriteConcern: 1)
time=2016-05-25T11:30:05.970UTC | lvl=INFO | trans=N/A | srv=N/A | subsrv=N/A | from=N/A | function=getWriteConcern | comp=Orion | msg=connectionOperations.cpp[724]: Database Operation Successful (getWriteConcern)
`
Do you think that this is related with the number of data that is being sent to Idas? and mongodb stopped due to maximum connections exceeding?
thanks
Orion shows the cannot connect to mongo - doing 100 retries with a 1000 microsecond interval error when the DB cannot be accessed, e.g. when the mongod server is down. I'm not an expert on IDAS, but I'd say that couldn't connect to server 172.17.0.2:27017 (172.17.0.2), connection attempt failed error is poiting to the same cause.
Thus, the solution to the problem is to ensure that MongoDB is up and running and accesible from Orion and IDAS.
Related
I have 3 etcd nodes on VMs (not k8s).
There was such problem that nodes are alive but can't see each other, error "connection timeout" during health check. But every single node has "alive" status and zabbix with "etcd by http" template doesn't generate any alerts.
Is there any way to check nodes visibility and to monitor it using zabbix?
Depending upon the version you run, here's an example to do this with 3.5.2
Command
ETCDCTL_API=3 ./bin/etcdctl endpoint status --cluster -w table --endpoints="member1.etcd:2384,member2.etcd:2384,member3.etcd:2384"
Output:
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------------------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| http://member1.etcd:2384 | 17ef476d9d7fec5f | 3.5.2 | 1.5 MB | false | false | 7 | 20033 | 20033 | |
| http://member2.etcd:2384 | 31e0ca30ec3c9d94 | 3.5.2 | 1.5 MB | false | false | 7 | 20033 | 20033 | |
| http://member3.etcd:2384 | 721948abbb0522bd | 3.5.2 | 1.5 MB | false | false | 7 | 20033 | 20033 | |
+--------------------------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
I have a remote MySQL database, and my deployed application (a few java microservice applications) consistently encounters the error ERROR 2013 (HY000): Lost connection to MySQL during query with some SQL queries. Then I tried to connect to mysql with MySQL command line client, executed the same query, and I managed to replicate the same error. Below is Mysql setup after following this page https://dev.mysql.com/doc/refman/5.7/en/error-lost-connection.html
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| connect_timeout | 3600 |
| delayed_insert_timeout | 300 |
| have_statement_timeout | YES |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 5 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 7200 |
| lock_wait_timeout | 50 |
| net_read_timeout | 3000 |
| net_write_timeout | 6000 |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_stop_slave_timeout | 31536000 |
| slave_net_timeout | 4 |
| wait_timeout | 7200 |
+------------------------------+----------+
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| max_allowed_packet | 1073741824 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+
However, I systematically have the same error after roughly 10 minutes after executing a big SQL query from the mysql command line client.
Note: On the DB server side, I notice the log [Note] Aborted connection xxxxx to db: 'xxxxx' user 'xxxxx' host 'xxxxx' (Got an error writing communication packets)
DBA executed the query successfully on the server on which mysql is installed. But we have to use mysql remotely as a service.
I will be grateful if anybody can help.
Finally, the root cause was a network issue. Our remote MySQL instance is exposed as service. There's an additional proxy between the client and MySQL DB. By default, the connection will be closed if no communication between client and server over 10 mins.
I've some problems with the commands in the IoTAgent JSON using MQTT. I follow these instructions:
POST ioat-agent:4041/iot/devices
{
"devices": [
{
"device_id": "id_lamp1",
"entity_name": "lamp1",
"entity_type": "lamp",
"attributes": [
{
"object_id": "l",
"name": "luminosity",
"type": "float"
}
],
"commands":[
{
"object_id": "u",
"name": "ping",
"type": "command"
}
],
"protocol": "IoTA-JSON",
"transport": "MQTT"
}
]
}
I try to send a command to the OCB. Something like that:
POST ocb:1026/v2/entities/lamp1/attrs?type=lamp
{
"ping":{
"type": "command",
"value": "Ping Request"
}
}
This appears to work fine, because I received in the log:
fiware-iot-agent | time=2019-05-16T09:42:00.436Z | lvl=DEBUG | corr=da768116-77be-11e9-8e17-0242ac140004 | trans=ed164f14-ffd8-404a-8da4-53b901d103b5 | op=IoTAgentNGSI.GenericMiddlewares | srv=myhome | subsrv=/environment | msg=Body:
fiware-iot-agent | {
fiware-iot-agent | "entities": [
fiware-iot-agent | {
fiware-iot-agent | "type": "lamp",
fiware-iot-agent | "isPattern": "false",
fiware-iot-agent | "id": "lamp1"
fiware-iot-agent | }
fiware-iot-agent | ],
fiware-iot-agent | "attributes": [
fiware-iot-agent | "ping"
fiware-iot-agent | ]
fiware-iot-agent | }
fiware-iot-agent | | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.457Z | lvl=DEBUG | corr=da768116-77be-11e9-8e17-0242ac140004 | trans=ed164f14-ffd8-404a-8da4-53b901d103b5 | op=IoTAgentNGSI.ContextServer | srv=myhome | subsrv=/environment | msg=Handling query from [iot-agent:4041] | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.462Z | lvl=DEBUG | corr=da768116-77be-11e9-8e17-0242ac140004 | trans=ed164f14-ffd8-404a-8da4-53b901d103b5 | op=IoTAgentNGSI.MongoDBDeviceRegister | srv=myhome | subsrv=/environment | msg=Looking for device with name [lamp1]. | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.481Z | lvl=DEBUG | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.MongoDBGroupRegister | srv=n/a | subsrv=n/a | msg=Looking for group params ["service","subservice","type"] with queryObj {"service":"myhome","subservice":"/environment","type":"lamp"} | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.489Z | lvl=DEBUG | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.MongoDBGroupRegister | srv=n/a | subsrv=n/a | msg=Device group for fields [["service","subservice","type"]] not found: [{"service":"myhome","subservice":"/environment","type":"lamp"}] | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.491Z | lvl=ERROR | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.Alarms | srv=n/a | subsrv=n/a | msg=Raising [MONGO-ALARM]: {"name":"DEVICE_GROUP_NOT_FOUND","message":"Couldn\t find device group","code":404} | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.495Z | lvl=DEBUG | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.ContextServer | srv=n/a | subsrv=n/a | msg=Handling received set of attributes: ["ping"] | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.496Z | lvl=DEBUG | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.MongoDBDeviceRegister | srv=n/a | subsrv=n/a | msg=Looking for device with name [lamp1]. | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.506Z | lvl=ERROR | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.Alarms | srv=n/a | subsrv=n/a | msg=Releasing [MONGO-ALARM] | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.509Z | lvl=DEBUG | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.ContextServer | srv=n/a | subsrv=n/a | msg=Query from [iot-agent:4041] handled successfully. | comp=IoTAgent
fiware-iot-agent | time=2019-05-16T09:42:00.511Z | lvl=DEBUG | corr=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | trans=3273f192-1cdc-42dc-80b1-9e0cab5a8a2b | op=IoTAgentNGSI.ContextServer | srv=n/a | subsrv=n/a | msg=Generated query response: {"contextResponses":[{"contextElement":{"type":"lamp","isPattern":false,"id":"lamp1","attributes":[{"name":"ping","type":"command","value":""}]},"statusCode":{"code":200,"reasonPhrase":"OK"}}]} | comp=IoTAgent
But I don't receive any message in the topic /1234/id_lamp1/cmd, and I don't see PENDING in the ring_status attribute of the entity of te OCB. Although when I simulate lamp1 device and publish a message in the /1234/id_lamp1/cmdexe the ring_status and ring_info change to OK and 22 respectively.
The problem is due to the usage of POST verb (in POST /v2/entities/lamp1/attrs?type=lamp) to send the command. POST has create semantics, so it will add the ping attribute to the entity instead of forwarding it to IOTA. Thus, the command never reaches the IOTA, so the IOTA never published in the MQTT broker. This is explained with more detail in the "Important Note" of this section of the documentation.
However, if you use PATCH instead POST (i.e.PATCH /v2/entities/lamp1/attrs?type=lamp) the forwarding takes place so IOTA receives the command and the IOTA will publish {"ping":"Ping Request"} in the /1234/id_lamp1/cmd topic in the MQTT broker.
If you already did POST /v2/entities/lamp1/attrs?type=lamp then first you have to fix the situation deleting the attribute with DELETE /v2/entities/lamp1/attrs/ping on the Orion Context Broker API. Otherwise the local ping attribute you created with POST will take preference over the ping registered attribute at IOTA when you do PATCH and forwarding will not take place.
I'm trying to model a rule for perseo CEP using esper time intervals (timer:interval), like the one documented on http://esper.espertech.com/release-6.1.0/esper-reference/html/event_patterns.html#pattern-atoms.
In particular this example which must be fire every 20 seconds is never executed:
{
"name": "timer_interval_update",
"text": "select *,\"timer_interval_update\" as ruleName from pattern [every timer:interval(20 sec)]",
"action": {
"type": "update",
"parameters": {
"id":"${id}",
"type":"A",
"attributes": [
{
"name": "status",
"value": "open",
"type": "text"
}
]
}
}
}
In the perseo-core log I'm receiving:
time=2018-07-31T19:17:11.821Z | lvl=INFO | from= | corr=n/a | trans=n/a | srv=n/a | subsrv=n/a | op=update | comp=perseo-core | msg=rule fired: WrapperEventBean [event=MapEventBean eventType=com.espertech.esper.event.map.MapEventType#7c584419] [properties={ruleName=timer_interval_update}]
time=2018-07-31T19:17:11.827Z | lvl=ERROR | from= | corr=n/a | trans=n/a | srv=n/a | subsrv=n/a | op=DoHTTPPost | comp=perseo-core | msg=exception IOException: java.net.SocketException: Unexpected end of file from server
time=2018-07-31T19:17:11.828Z | lvl=ERROR | from= | corr=n/a | trans=n/a | srv=n/a | subsrv=n/a | op=update | comp=perseo-core | msg=action post failed
I'm using a dockerized environment using this docker-compose:
https://github.com/aguirrea/fiware-perseo-test.git
So the problem is that when i try to establish a connection with the Context Broker whether i'm trying to update the entity or read the values. It only responds ok when i ask a second time.
Context Broker Version: 0.24.0 (i updated from 0.20.0 because i thought that was the problem)
Example:
python2.7 GetEntity.py entity_1
Output:
* Asking to http://188.***.**.***:1026/ngsi10/queryContext
* Headers: {'Fiware-Service': 'fiwarefinal', 'content-type': 'application/json', 'accept': 'application/json', 'X-Auth-Token': 'NULL'}
* Sending PAYLOAD:
{
"entities": [
{
"type": "",
"id": "entity_1",
"isPattern": "false"
}
],
"attributes": []
}
...
Traceback (most recent call last):
File "GetEntity.py", line 73, in <module>
r = requests.post(URL, data=PAYLOAD, headers=HEADERS)
File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 109, in post
return request('post', url, data=data, json=json, **kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 50, in request
response = session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 415, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
When i do it a second time:
* Asking to http://188.***.**.***:1026/ngsi10/queryContext
* Headers: {'Fiware-Service': 'fiwarefinal', 'content-type': 'application/json', 'accept': 'application/json', 'X-Auth-Token': 'NULL'}
* Sending PAYLOAD:
{
"entities": [
{
"type": "",
"id": "entity_1",
"isPattern": "false"
}
],
"attributes": []
}
...
* Status Code: 200
* Response:
{
"contextResponses" : [
{
"contextElement" : {
"type" : "",
"isPattern" : "false",
"id" : "entity_1",
"attributes" : [
{
"name" : "humidity",
"type" : "int",
"value" : "4"
},
{
"name" : "latitude",
"type" : "float",
"value" : "3"
},
{
"name" : "longitude",
"type" : "float",
"value" : "5"
},
{
"name" : "temperature",
"type" : "int",
"value" : "8"
}
]
},
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
}
]
}
Example Nrº 2:
curl http://188.***.**.***:1026/version
Output:
curl: (56) Failure when receiving data from the peer
And when i do it a second time:
<orion>
<version>0.24.0</version>
<uptime>0 d, 0 h, 41 m, 27 s</uptime>
<git_hash><deleted for safety reasons></git_hash>
<compile_time>Mon Sep 14 17:52:44 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
Sometimes i even have to restart because when i check the status of the Context Broker it gives me an error. I'm not sure of the error but i think it's something like "the pid file doesn't exist"
EDIT:
EDIT 2:
So i tried using the script from Fiware-Figway:
python2.7 GetEntity.py entity_1
and as expected because of the problem, it worked half the times.
Full log trace for the Context Broker:
time=2015-10-01T11:31:09.269EDT | lvl=INFO | trans=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1509]: Orion Context Broker is running
time=2015-10-01T11:31:09.280EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.280EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.281EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.282EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.282EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.283EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.283EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.284EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.284EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.285EDT | lvl=INFO | trans=N/A | function=mongoConnect | comp=Orion | msg=mongoConnectionPool.cpp[196]: Successful connection to database
time=2015-10-01T11:31:09.285EDT | lvl=INFO | trans=N/A | function=mongoInit | comp=Orion | msg=contextBroker.cpp[1289]: Connected to mongo at localhost:orion
time=2015-10-01T11:31:09.286EDT | lvl=INFO | trans=N/A | function=getOrionDatabases | comp=Orion | msg=MongoGlobal.cpp[283]: Database Operation Successful (listDatabases command)
time=2015-10-01T11:31:09.286EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:09.287EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:09.288EDT | lvl=INFO | trans=N/A | function=treatOnTimeIntervalSubscriptions | comp=Orion | msg=MongoGlobal.cpp[553]: Database Operation Successful ({ conditions.type: "ONTIMEINTERVAL" })
time=2015-10-01T11:31:09.288EDT | lvl=INFO | trans=N/A | function=main | comp=Orion | msg=contextBroker.cpp[1597]: Startup completed
time=2015-10-01T11:31:18.112EDT | lvl=INFO | trans=1443713469-276-00000000001 | function=connectionTreat | comp=Orion | msg=rest.cpp[910]: Starting transaction from 127.0.0.1:45867/version
time=2015-10-01T11:31:18.114EDT | lvl=INFO | trans=1443713469-276-00000000001 | function=requestCompleted | comp=Orion | msg=rest.cpp[442]: Transaction ended
time=2015-10-01T11:31:19.289EDT | lvl=INFO | trans=N/A | function=getOrionDatabases | comp=Orion | msg=MongoGlobal.cpp[283]: Database Operation Successful (listDatabases command)
time=2015-10-01T11:31:19.290EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:19.290EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:29.292EDT | lvl=INFO | trans=N/A | function=getOrionDatabases | comp=Orion | msg=MongoGlobal.cpp[283]: Database Operation Successful (listDatabases command)
time=2015-10-01T11:31:29.293EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:29.293EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:39.294EDT | lvl=INFO | trans=N/A | function=getOrionDatabases | comp=Orion | msg=MongoGlobal.cpp[283]: Database Operation Successful (listDatabases command)
time=2015-10-01T11:31:39.295EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:39.295EDT | lvl=INFO | trans=N/A | function=subscriptionsTreat | comp=Orion | msg=MongoGlobal.cpp[2911]: Database Operation Successful ({})
time=2015-10-01T11:31:39.427EDT | lvl=INFO | trans=1443713469-276-00000000002 | function=connectionTreat | comp=Orion | msg=rest.cpp[910]: Starting transaction from 188.***.**.***:58440/ngsi10/queryContext
time=2015-10-01T11:31:39.442EDT | lvl=INFO | trans=1443713469-276-00000000002 | function=entitiesQuery | comp=Orion | msg=MongoGlobal.cpp[1616]: Database Operation Successful ({ query: { $or: [ { _id.id: "entity_1" } ], _id.servicePath: { $in: [ null, /^$/, /^/.*/ ] } }, orderby: { creDate: 1 } })
time=2015-10-01T11:31:39.444EDT | lvl=INFO | trans=1443713469-276-00000000002 | function=registrationsQuery | comp=Orion | msg=MongoGlobal.cpp[2206]: Database Operation Successful ({ query: { $or: [ { contextRegistration.entities: { $in: [] } }, { contextRegistration.entities.id: { $in: [ "entity_1" ] } } ], expiration: { $gt: 1443713499 }, servicePath: { $in: [ null, /^$/, /^/.*/ ] } }, orderby: { _id: 1 } })
time=2015-10-01T11:31:39.453EDT | lvl=INFO | trans=1443713469-276-00000000002 | function=requestCompleted | comp=Orion | msg=rest.cpp[442]: Transaction ended
So as refered on this post's answer, there is a RAM memory issue regarding this problem. In fact my VM was running low on memory after a lot of testing and that itself made the Context Broker have this problem. I freed the memory and now the issue is gone.