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

        fla Fernando Lopez made changes -
        Fix Version/s 2021 [ 12600 ]
        backlogmanager Backlog Manager made changes -
        Summary [fiware-stackoverflow] Fiware - Cygnus: Issue with collection&#39;s names FIWARE.Question.Tech.Data.BigData-Analysis.Fiware - Cygnus: Issue with collection&#39;s names
        HD-Chapter Data [ 10838 ]
        backlogmanager Backlog Manager made changes -
        Resolution Done [ 10000 ]
        Status In Progress [ 3 ] Closed [ 6 ]
        mev Manuel Escriche made changes -
        Resolution Done [ 10000 ]
        Status Closed [ 6 ] In Progress [ 3 ]
        mev Manuel Escriche made changes -
        Resolution Fixed [ 1 ] Done [ 10000 ]
        Status Answered [ 10104 ] Closed [ 6 ]
        mev Manuel Escriche made changes -
        Status In Progress [ 3 ] Answered [ 10104 ]
        mev Manuel Escriche made changes -
        Description
        Created question in FIWARE Q/A platform on 10-03-2016 at 16:03
        {color: red}Please, ANSWER this question AT{color} http://stackoverflow.com/questions/35921306/fiware-cygnus-issue-with-collections-names


        +Question:+
        Fiware - Cygnus: Issue with collection&#39;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) &lt;&lt;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) &lt;&lt;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?
        Created question in FIWARE Q/A platform on 10-03-2016 at 16:03
        {color: red}Please, ANSWER this question AT{color} http://stackoverflow.com/questions/35921306/fiware-cygnus-issue-with-collections-names


        +Question:+
        Fiware - Cygnus: Issue with collection&#39;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) &lt;&lt;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) &lt;&lt;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?
        Resolution Fixed [ 1 ]
        HD-Enabler Cosmos [ 10872 ]
        frb Francisco Romero made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        mev Manuel Escriche made changes -
        Assignee Francisco Romero [ frb ]
        backlogmanager Backlog Manager made changes -
        Field Original Value New Value
        Component/s FIWARE-TECH-HELP [ 10278 ]
        backlogmanager Backlog Manager created issue -

          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: