Feature: Make transport-netty-http/transport-simple-http support posting

[jasonjoo2010]

Make transport layer support parameters in post body

Describe what this PR does / why we need it

include netty-http and simple-http

Does this pull request fix one issue?

#618

[CLAassistant]

All committers have signed the CLA.

[codecov-io]

Codecov Report

Merging #667 into master will increase coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #667      +/-   ##
============================================
+ Coverage      41.1%   41.13%   +0.03%     
- Complexity     1216     1335     +119     
============================================
  Files           267      284      +17     
  Lines          7854     8925    +1071     
  Branches       1062     1193     +131     
============================================
+ Hits           3228     3671     +443     
- Misses         4233     4791     +558     
- Partials        393      463      +70

Impacted Files	Coverage Δ	Complexity Δ
...l/cluster/server/connection/ConnectionManager.java	74% <0%> (-2%)	10% <0%> (-1%)
...a/com/alibaba/csp/sentinel/node/StatisticNode.java	56.17% <0%> (-1.13%)	28% <0%> (-1%)
.../alibaba/csp/sentinel/eagleeye/FastDateFormat.java	78.37% <0%> (ø)	6% <0%> (?)
...com/alibaba/csp/sentinel/eagleeye/TokenBucket.java	35.29% <0%> (ø)	1% <0%> (?)
...a/csp/sentinel/slots/statistic/base/Striped64.java	61.45% <0%> (ø)	11% <0%> (?)
...libaba/csp/sentinel/eagleeye/EagleEyeAppender.java	14.28% <0%> (ø)	1% <0%> (?)
...sentinel/eagleeye/EagleEyeRollingFileAppender.java	28.9% <0%> (ø)	11% <0%> (?)
...a/com/alibaba/csp/sentinel/eagleeye/StatEntry.java	20.21% <0%> (ø)	8% <0%> (?)
...om/alibaba/csp/sentinel/eagleeye/SyncAppender.java	53.57% <0%> (ø)	5% <0%> (?)
...ibaba/csp/sentinel/eagleeye/StatLogController.java	65.93% <0%> (ø)	5% <0%> (?)
... and 10 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b02ef82...211bd06. Read the comment docs.

[jasonjoo2010]

Because another unstable unit test WarmUpRateLimiterControllerTest this PR also make it stable to pass travis

[sczyh30]

Because another unstable unit test WarmUpRateLimiterControllerTest this PR also make it stable to pass travis

👍

[sczyh30]

Seems that ClusterNodeTest.testGetOrCreateOriginNodeMultiThread is also unstable. I think it might be caused by line 98:

Node node = clusterNode.getOrCreateOriginNode(origins.get(random.nextInt(origins.size())));

The line will get origin randomly from the origin array. In rare circumstances, not all origins can be visited. Could you please fix it?

[jasonjoo2010]

Seems that ClusterNodeTest.testGetOrCreateOriginNodeMultiThread is also unstable. I think it might be caused by line 98:

Node node = clusterNode.getOrCreateOriginNode(origins.get(random.nextInt(origins.size())));

The line will get origin randomly from the origin array. In rare circumstances, not all origins can be visited.

Yeah, i found i seems like suffering unstable tests now

[jasonjoo2010]

Seems that ClusterNodeTest.testGetOrCreateOriginNodeMultiThread is also unstable. I think it might be caused by line 98:

Node node = clusterNode.getOrCreateOriginNode(origins.get(random.nextInt(origins.size())));

The line will get origin randomly from the origin array. In rare circumstances, not all origins can be visited.

I think in rare condition this random algorithm may miss the assertion.

eg.

What is expected as:

origin	count
origin1	7
origin2	7
origin3	6

But maybe happen:

origin	count
origin1	10
origin2	10
origin3	0

And it will fail.

Should we consist on the random algorithm and introduce sth. like Set to indicate what has been actually hit or just make it a RoundRobin like algorithm?

[sczyh30]

Seems that ClusterNodeTest.testGetOrCreateOriginNodeMultiThread is also unstable. I think it might be caused by line 98:

Node node = clusterNode.getOrCreateOriginNode(origins.get(random.nextInt(origins.size())));

The line will get origin randomly from the origin array. In rare circumstances, not all origins can be visited.

I think in rare condition this random algorithm may miss the assertion.

eg.

What is expected as:

origin count
origin1 7
origin2 7
origin3 6
But maybe happen:

origin count
origin1 10
origin2 10
origin3 0
And it will fail.

Should we consist on the random algorithm and introduce sth. like Set to indicate what has been actually hit or just make it a RoundRobin like algorithm?

Yes, maybe we can just make it a round robin (taskCount % originSize).

[jasonjoo2010]

Done with it.

And it's strange only this PR suffers unstable unit tests frequently.

[sczyh30]

Good job. Unstable test cases often fail when merging into master (and we have to manually restart the CI job to retry)

[sczyh30]

Seems that the CLA status is expired? Could you please check the CLA status of your GitHub account?

[jasonjoo2010]

Seems that the CLA status is expired? Could you please check the CLA status of your GitHub account?

It's just because default email is internal address and i forgot to override it when commit.

Now it's ok

[sczyh30]

LGTM

[sczyh30]

Nice work. Thanks for contributing!

[cdfive]

@jasonjoo2010 @sczyh30 Oh, I'm sorry for make ClusterNodeTest.testGetOrCreateOriginNodeMultiThread unstable, neglecting the random rare condition. Thanks to fix it!