Uploaded image for project: 'Help-Desk'
  1. Help-Desk
  2. HELP-6100

FIWARE.Question.Tech.Data.BigData-Analysis.Fiware - Cygnus: Issue with collection's names

    Details

      Description

      Created question in FIWARE Q/A platform on 10-03-2016 at 16:03
      Please, ANSWER this question AT http://stackoverflow.com/questions/35921306/fiware-cygnus-issue-with-collections-names

      Question:
      Fiware - Cygnus: Issue with collection's names

      Description:
      I have encountered a strange behaviour on the Cygnus module. I’m using Context Broker version 0.28 and Cygnus version 0.13. Let’s suppose that I have loaded on the CB (Context Broker) some entities similars to this one:

      (curl 172.21.0.33:1026/v1/updateContext -s -S
      --header 'Fiware-Service: cb33_1003_06'
      --header 'Fiware-ServicePath: /Lugar'
      --header 'Content-Type: application/json'
      -header 'Accept: application/json' -d @ | python -mjson.tool) <<EOF

      {
      "contextElements": [
      {
      "type": "Acceso_Wifi",
      "isPattern": "false",
      "id": "AP_1.3",
      "attributes": [

      { "name": "temperature", "type": "float", "value": "25" }

      ,

      { "name": "pressure", "type": "integer", "value": "1" }

      ,
      {
      "name": "position",
      "type": "coords",
      "value": "13.322326, -1.983824",
      "metadatas": [

      { "name": "location", "type": "string", "value": "WGS84" }

      ]
      }
      ]
      }
      ],
      "updateAction": "APPEND"
      }

      EOF

      And now I subscribe the Cygnus:

      (curl 172.21.0.33:1026/v1/subscribeContext -s -S
      --header 'Fiware-Service: cb33_1003_06'
      --header 'Fiware-ServicePath: /Lugar'
      --header 'Content-Type: application/json'
      -header 'Accept: application/json' -d @ | python -mjson.tool) <<EOF
      {
      "entities": [

      { "type": "Acceso_Wifi", "isPattern": "true", "id": "AP_.*" }

      ],
      "attributes": [
      "temperature",
      "pressure"
      ],
      "reference": "http://172.21.0.33:5050/notify",
      "duration": "P1M",
      "notifyConditions": [

      { "type": "ONCHANGE", "condValues": [] }

      ],
      "throttling": "PT1S"
      }
      EOF

      The CB will send one notification to the Cygnus for each matching entity loaded previously on the CB database. Let’s assume that there are 3 entities that meet the subscription’s criteria. In that case, one collection will be created on the Cygnus for each one of these entities (I’m using the default dm-by-entity data model). The problem is that the collection's name are not well formed. The Fiware-ServicePath is concatenated once per each entity, on each collection name:

      cygnus2_/Lugar_Lugar_Lugar_AP_1.1_Acceso_Wifi
      cygnus2_/Lugar_Lugar_Lugar_AP_1.2_Acceso_Wifi
      cygnus2_/Lugar_Lugar_Lugar_AP_1.3_Acceso_Wifi

      If we update one of these entities, a new collection will be created with a correct name:

      cygnus2_/Lugar_AP_1.1_Acceso_Wifi
      cygnus2_/Lugar_Lugar_Lugar_AP_1.1_Acceso_Wifi
      cygnus2_/Lugar_Lugar_Lugar_AP_1.2_Acceso_Wifi
      cygnus2_/Lugar_Lugar_Lugar_AP_1.3_Acceso_Wifi

      On this example there were just 3 entities, but as the amount of matching entities increases, the longer will be the collection's name. And when it arrives to 50 characters, a warning will be raised and no collection will be created.

      org.apache.flume.source.http.HTTPBadRequestException: 'fiware-servicePath' header length greater than 50)
      at com.telefonica.iot.cygnus.handlers.OrionRestHandler.getEvents(OrionRestHandler.java:209)
      at org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet.doPost(HTTPSource.java:184)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
      at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
      at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
      at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
      at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
      at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
      at org.mortbay.jetty.Server.handle(Server.java:326)
      at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
      at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
      at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
      at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
      at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
      at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
      at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

      ¿It’s that behaviour due to an incorrect configuration, or it’s Cygnus’s problem?

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        3d 23h 3m 1 Francisco Romero 14/Mar/16 5:05 PM
        In Progress In Progress Answered Answered
        21d 23h 54m 1 Manuel Escriche 05/Apr/16 6:00 PM
        Answered Answered Closed Closed
        2s 1 Manuel Escriche 05/Apr/16 6:00 PM
        Closed Closed In Progress In Progress
        1s 1 Manuel Escriche 05/Apr/16 6:00 PM
        In Progress In Progress Closed Closed
        2m 26s 1 Backlog Manager 05/Apr/16 6:02 PM

          People

          • Assignee:
            frb Francisco Romero
            Reporter:
            backlogmanager Backlog Manager
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: