Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix distributed aggregative query error #4940

Merged
merged 3 commits into from
Dec 9, 2015
Merged

Fix distributed aggregative query error #4940

merged 3 commits into from
Dec 9, 2015

Conversation

li-ang
Copy link

@li-ang li-ang commented Dec 1, 2015

Fix issue #4937 issue #4965
When distributed aggregative query covers two more seriesKeys(measurement + tagSets) in a shard file, the aggregative query result which is passed accross cluster, would has two more mapperValues. The node of cluster, revieving the aggregative query result, could regard the query result as raw query result. It will lead to ERR: unexpected end of JSON input or double results described by issue #4965 .

  • CHANGELOG.md updated
  • Rebased/mergable
  • Tests pass
  • Sign CLA

@li-ang li-ang changed the title Fix distributed aggregative query error (WIP)Fix distributed aggregative query error Dec 1, 2015
@li-ang li-ang changed the title (WIP)Fix distributed aggregative query error Fix distributed aggregative query error Dec 2, 2015
@li-ang
Copy link
Author

li-ang commented Dec 2, 2015

@otoolep Can you review the PR?

@corylanou
Copy link
Contributor

I would like to hold off on merging this until we merge #4848. This will allow us to write a cluster test to make sure we don't regress. Hopefully we can merge the cluster test PR today.

@corylanou
Copy link
Contributor

Ok, that PR is merged. I'm happy to write the test for you if you can give me an idea of what type of query was failing before. If you can provide a couple of sample writes with a query that should be all I need to reproduce in the master branch.

@li-ang
Copy link
Author

li-ang commented Dec 3, 2015

@corylanou
I suggest you should create a InfluxDB cluster and set replication of the retention policy as 1. Then, write some points _which are different from tagSets_ . At last, execute a aggregative query which can _cover all points_ you write in.

The following is a repreduce sample:

Create InfluxDB cluster with three node. There is cluster stats:

> show servers
id  cluster_addr    raft    raft-leader
1   127.0.0.1:8088  true    true
2   127.0.0.1:9099  true    false
3   127.0.0.1:10101 true    false

Create a database named foo and a retention policy named one_hour with duration 1h and replication 1:

> create database foo
> create retention policy one_hour on foo duration 1h replication 1
> show databases
name: databases
---------------
name
foo

> show retention policies on foo
name        duration    replicaN    default
default     0       3       true
one_hour    1h0m0s      1       false

> 

Write several points to one_hour retention policy of foo database using curl:

➜  ~  curl -i -XPOST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_1,region=region_1 value=1'
HTTP/1.1 204 No Content
Request-Id: 0632942a-98a4-11e5-8013-000000000000
X-Influxdb-Version: 0.9
Date: Wed, 02 Dec 2015 03:23:15 GMT
Connection: close

➜  ~  curl -i -XPOST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_2,region=region_2 value=2'
HTTP/1.1 204 No Content
Request-Id: 0c490066-98a4-11e5-8014-000000000000
X-Influxdb-Version: 0.9
Date: Wed, 02 Dec 2015 03:23:25 GMT
Connection: close

➜  ~  curl -i -XPOST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_3,region=region_3 value=3'
HTTP/1.1 204 No Content
Request-Id: 100443e8-98a4-11e5-8015-000000000000
X-Influxdb-Version: 0.9
Date: Wed, 02 Dec 2015 03:23:31 GMT
Connection: close

➜  ~  curl -i -XPOST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_4,region=region_4 value=4'
HTTP/1.1 204 No Content
Request-Id: 1432f71e-98a4-11e5-8016-000000000000
X-Influxdb-Version: 0.9
Date: Wed, 02 Dec 2015 03:23:38 GMT
Connection: close

Now, there are four points in foo database:

➜  ~  curl -G 'http://127.0.0.1:8086/query?pretty=true' --data-urlencode "db=foo" --data-urlencode "q=SELECT * FROM one_hour.cpu"          
{
    "results": [
        {
            "series": [
                {
                    "name": "cpu",
                    "columns": [
                        "time",
                        "host",
                        "region",
                        "value"
                    ],
                    "values": [
                        [
                            "2015-12-02T03:23:15.070506552Z",
                            "host_1",
                            "region_1",
                            1
                        ],
                        [
                            "2015-12-02T03:23:25.283799043Z",
                            "host_2",
                            "region_2",
                            2
                        ],
                        [
                            "2015-12-02T03:23:31.544199738Z",
                            "host_3",
                            "region_3",
                            3
                        ],
                        [
                            "2015-12-02T03:23:38.561141279Z",
                            "host_4",
                            "region_4",
                            4
                        ]
                    ]
                }
            ]
        }
    ]
}

use mean or other functions to execute aggregative query:

 ➜  ~  curl -G 'http://127.0.0.1:8086/query?pretty=true' --data-urlencode "db=foo" --data-urlencode "q=SELECT mean(value) FROM one_hour.cpu"
{
    "results": [
        {
            "error": "unexpected end of JSON input"
        }
    ]
}
➜  ~  curl -G 'http://127.0.0.1:8086/query?pretty=true' --data-urlencode "db=foo" --data-urlencode "q=SELECT sum(value) FROM one_hour.cpu"
{
    "results": [
        {
            "error": "unexpected end of JSON input"
        }
    ]
}
➜  ~  curl -G 'http://127.0.0.1:8086/query?pretty=true' --data-urlencode "db=foo" --data-urlencode "q=SELECT min(value) FROM one_hour.cpu"
{
    "results": [
        {
            "error": "unexpected end of JSON input"
        }
    ]
}
➜  ~  curl -G 'http://127.0.0.1:8086/query?pretty=true' --data-urlencode "db=foo" --data-urlencode "q=SELECT max(value) FROM one_hour.cpu"
{
    "results": [
        {
            "error": "unexpected end of JSON input"
        }
    ]
}

@li-ang
Copy link
Author

li-ang commented Dec 3, 2015

@corylanou
The followings are curl command.

curl -G 'http://127.0.0.1:8086/query' --data-urlencode "q=create database foo"
curl -G 'http://127.0.0.1:8086/query' --data-urlencode "q=create retention policy one_hour on foo duration 1h replication 1"
curl -X POST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_1,region=region_1 value=1'
curl -X POST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_2,region=region_2 value=2'
curl -X POST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_3,region=region_3 value=3'
curl -X POST 'http://127.0.0.1:8086/write?db=foo&rp=one_hour' --data-binary 'cpu,host=host_4,region=region_4 value=4'

@otoolep
Copy link
Contributor

otoolep commented Dec 7, 2015

@dgnorton @corylanou -- what do you think? Should we get this in for 0.9.6?

@li-ang
Copy link
Author

li-ang commented Dec 7, 2015

@otoolep Please wait a miniute, I will add some commits to this pr.

@li-ang
Copy link
Author

li-ang commented Dec 7, 2015

@otoolep Done!

@otoolep
Copy link
Contributor

otoolep commented Dec 8, 2015

Thanks @li-ang

@dgnorton @corylanou -- what do you think?

@corylanou
Copy link
Contributor

We have no testing around this yet. It passes the existing tests so it doesn't introduce any new single node bugs that we are aware of. We can add more tests in a following PR if you want to ship this.

otoolep added a commit that referenced this pull request Dec 9, 2015
Fix distributed aggregative query error
@otoolep otoolep merged commit da08304 into influxdata:master Dec 9, 2015
@otoolep
Copy link
Contributor

otoolep commented Dec 9, 2015

Thanks @li-ang

@li-ang li-ang deleted the fix_aggregative_query_err branch December 10, 2015 02:34
@jwilder jwilder added this to the 0.10.0 milestone Feb 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants