[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516592#comment-16516592 ] ASF GitHub Bot commented on SCB-651: liubao68 closed pull request #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java b/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java index 401430747..8bc147b8c 100644 --- a/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java +++ b/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java @@ -31,7 +31,7 @@ private AtomicLong requestCount = new AtomicLong(); // 本周期之前的请求数 - private volatile long lastRequestCount = 0; + private volatile long lastRequestCount = 1; private static final int CYCLE_LENGTH = 1000; This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516580#comment-16516580 ] ASF GitHub Bot commented on SCB-651: coveralls edited a comment on issue #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#issuecomment-397202923 [](https://coveralls.io/builds/17561719) Coverage decreased (-0.04%) to 87.321% when pulling **7aa7cdba3f590a6cfc776757b7b21393b0ed3c54 on limbojinne:patch-1** into **b81196f6eedf220dfb87b77b3a548cd201a7f3ac on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516535#comment-16516535 ] ASF GitHub Bot commented on SCB-651: liubao68 closed pull request #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java b/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java index 401430747..8bc147b8c 100644 --- a/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java +++ b/handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java @@ -31,7 +31,7 @@ private AtomicLong requestCount = new AtomicLong(); // 本周期之前的请求数 - private volatile long lastRequestCount = 0; + private volatile long lastRequestCount = 1; private static final int CYCLE_LENGTH = 1000; This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516536#comment-16516536 ] ASF GitHub Bot commented on SCB-651: limbojinne opened a new pull request #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770 Added the logic for the first cycle of qps controller so that the number of requests allowed per second equals to its limit value. Follow this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SCB) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SCB-XXX] Fixes bug in ApproximateQuantiles`, where you replace `SCB-XXX` with the appropriate JIRA issue. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] If this contribution is large, please file an Apache [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). --- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16513213#comment-16513213 ] ASF GitHub Bot commented on SCB-651: limbojinne commented on issue #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#issuecomment-397486140 Okay, I've changed lastRequestCount to 1, thanks This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512389#comment-16512389
]
ASF GitHub Bot commented on SCB-651:
liubao68 commented on a change in pull request #770: [SCB-651] Fixes bug of qps
rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195400342
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
Change lastRequestCount to 1 is preferred. Thanks
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512362#comment-16512362
]
ASF GitHub Bot commented on SCB-651:
limbojinne commented on a change in pull request #770: [SCB-651] Fixes bug of
qps rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195391793
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
It is. So do you want me to keep the code this way or change
lastRequestCount to 1?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512351#comment-16512351
]
ASF GitHub Bot commented on SCB-651:
liubao68 commented on a change in pull request #770: [SCB-651] Fixes bug of qps
rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195389425
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
If you change lastRequestCount to 1, the algorithm is consistent. Because
for next cycles it's initial value is the newCount, not newCount - 1. This can
be a minor fix.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512213#comment-16512213
]
ASF GitHub Bot commented on SCB-651:
limbojinne commented on a change in pull request #770: [SCB-651] Fixes bug of
qps rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195353249
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
But why only set the limit in the first cycle higher than the expected value
at the beginning? After the first cycle, the number of successful requests in
the following new cycles will still be equal to the limit value. The
modification is supposed to keep the logic consistent both in the first cycle
and the following new cycles.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512171#comment-16512171
]
ASF GitHub Bot commented on SCB-651:
yangbor commented on a change in pull request #770: [SCB-651] Fixes bug of qps
rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195344393
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
I agree with liubao's opinion. It's impractical to make the actual qps
exactly equal to the configured limit. Thus the fix is not needed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512155#comment-16512155
]
ASF GitHub Bot commented on SCB-651:
limbojinne commented on a change in pull request #770: [SCB-651] Fixes bug of
qps rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195340419
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
Yes, it's same as setting lastRequestCount = 1. I separate the assignment
clause since this issue only occurs at the beginning (i.e. in the first cycle),
but the following cycles operate just as expected.
I committed this modification because I was expecting the number of requests
allowed per second should be equal to the qps limit value. For example, 5
successful requests when setting limit value as 5, no matter that's in a first
cycle or new cycles.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512152#comment-16512152
]
ASF GitHub Bot commented on SCB-651:
limbojinne commented on a change in pull request #770: [SCB-651] Fixes bug of
qps rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195340419
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
Yes, it's same as setting lastRequestCount = 1. I separate the assignment
clause since this issue only occurs at the beginning (i.e. in the first cycle),
but the following cycles operate just as expected.
I committed this modification because I was expecting the number of requests
allowed per second should be equal to the qps limit value. For example, 5
successful requests when setting limit value as 5.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[
https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512119#comment-16512119
]
ASF GitHub Bot commented on SCB-651:
liubao68 commented on a change in pull request #770: [SCB-651] Fixes bug of qps
rate limit value
URL:
https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#discussion_r195332212
##
File path:
handlers/handler-flowcontrol-qps/src/main/java/org/apache/servicecomb/qps/QpsController.java
##
@@ -57,6 +60,11 @@ public void setQpsLimit(Integer qpsLimit) {
public boolean isLimitNewRequest() {
long newCount = requestCount.incrementAndGet();
long msNow = System.currentTimeMillis();
+if (firstCycle) {
Review comment:
Is this solution the same as set lastRequestCount = 1?
In concurrent scenario, flow control is not work very precisely as the
configured rate. In practice, we can not assume a concrete rate and will set
the limit a bit higher than the expected value.
So I think this modification is not quit necessary.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> QPS rate limit bug
> --
>
> Key: SCB-651
> URL: https://issues.apache.org/jira/browse/SCB-651
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
>Affects Versions: java-chassis-1.0.0-m1
>Reporter: Sean Li
>Assignee: Sean Li
>Priority: Major
> Attachments: limit value as 1.jpeg, limit value as 2.jpeg
>
>
> When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the
> actual number of requests allowed per second are 1 less than the limit value.
>
> For example, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 1, I'll get NO successful request at the very
> beginning, although I would expect 1 successful request instead of none.
> Similarly, if I set _flowcontrol.Provider.qps.limit._
> _business-service-consumer_ as 2, I'll get 1 successful request instead of
> 2.
>
> -However, if I pause before sending requests, for example add
> _Thread.sleep(100)_ before invoking the first request, the number of requests
> allowed per second will be correct this time. (i.e. 1 successful request when
> limit value is 1, 2 successful requests when limit value is 2, etc.)-
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512099#comment-16512099 ] ASF GitHub Bot commented on SCB-651: coveralls commented on issue #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770#issuecomment-397202923 [](https://coveralls.io/builds/17485864) Coverage increased (+0.02%) to 87.377% when pulling **2f4912fa7a05234c4ef864df3a0735de3c561c39 on limbojinne:patch-1** into **b81196f6eedf220dfb87b77b3a548cd201a7f3ac on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512056#comment-16512056 ] ASF GitHub Bot commented on SCB-651: limbojinne opened a new pull request #770: [SCB-651] Fixes bug of qps rate limit value URL: https://github.com/apache/incubator-servicecomb-java-chassis/pull/770 Added the logic for the first cycle of qps controller so that the number of requests allowed per second equals to its limit value. Follow this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SCB) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SCB-XXX] Fixes bug in ApproximateQuantiles`, where you replace `SCB-XXX` with the appropriate JIRA issue. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] If this contribution is large, please file an Apache [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). --- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Assignee: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second are 1 less than the limit value. > > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of > 2. > > -However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.)- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCB-651) QPS rate limit bug
[ https://issues.apache.org/jira/browse/SCB-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504206#comment-16504206 ] Sean Li commented on SCB-651: - In attachments, _limit value as 1.jpeg_ is the outcome when I set flowcontrol.Provider.qps.limit. business-service-consumer as 1, and there's no successful request. _limit value as 2.jpeg_ is the outcome when I set flowcontrol.Provider.qps.limit. business-service-consumer as 2, and there's only 1 successful request (i.e. *0: Hello World! uuid: 6a550e8d-baa9-46bb-b8f2-f54b7b67b883*). > QPS rate limit bug > -- > > Key: SCB-651 > URL: https://issues.apache.org/jira/browse/SCB-651 > Project: Apache ServiceComb > Issue Type: Bug > Components: Java-Chassis >Affects Versions: java-chassis-1.0.0-m1 >Reporter: Sean Li >Priority: Major > Attachments: limit value as 1.jpeg, limit value as 2.jpeg > > > When setting _servicecomb.flowcontrol.Provider.qps.limit.[ServiceName]_, the > actual number of requests allowed per second is always 1 less than the limit > value. > For example, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 1, I'll get NO successful request at the very > beginning, although I would expect 1 successful request instead of none. > Similarly, if I set _flowcontrol.Provider.qps.limit._ > _business-service-consumer_ as 2, I'll get 1 successful request instead of 2. > > However, if I pause before sending requests, for example add > _Thread.sleep(100)_ before invoking the first request, the number of requests > allowed per second will be correct this time. (i.e. 1 successful request when > limit value is 1, 2 successful requests when limit value is 2, etc.) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
