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
        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 ]
        Hide
        backlogmanager Backlog Manager added a comment -

        2016-04-05 18:05|UPDATED status: transition Finish| # answers= 1, accepted answer= True

        Show
        backlogmanager Backlog Manager added a comment - 2016-04-05 18:05|UPDATED status: transition Finish| # answers= 1, accepted answer= True
        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 ]
        Hide
        backlogmanager Backlog Manager added a comment -

        2016-03-10 18:05|CREATED monitor | # answers= 0, accepted answer= False

        Show
        backlogmanager Backlog Manager added a comment - 2016-03-10 18:05|CREATED monitor | # answers= 0, accepted answer= False
        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: