You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by GitBox <gi...@apache.org> on 2022/08/18 03:13:42 UTC
[GitHub] [rocketmq] 15712852007 opened a new issue, #4838: send async, time calculation problem
15712852007 opened a new issue, #4838:
URL: https://github.com/apache/rocketmq/issues/4838
In the process of the production of our company, there have been many times in this case, the client RemotingTooMuchRequestException interval when a large number of appear, the client is using asynchronous send, after a long time trying to find, asynchronous transmission due to network jitter at the core of the threads are blocked, At this time, the QPS of the service is also large, there are a large number of backlogged tasks in the blocking queue, and when the network is restored, there will be a large number of timeouts, so I strongly believe that the time here is more appropriate from the moment the task starts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lwclover commented on issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
lwclover commented on issue #4838:
URL: https://github.com/apache/rocketmq/issues/4838#issuecomment-1220117950
There is a situation where the broker is slow in processing messages.
If timeouts are calculated from before messages are placed in the thread pool,
When the thread pool is full, and subsequent messages are discarded.
Messages in the thread pool may also be discarded due to timeouts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lwclover commented on issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
lwclover commented on issue #4838:
URL: https://github.com/apache/rocketmq/issues/4838#issuecomment-1225044097
> @15712852007 @lwclover I am the original designer of this scheme. Here are the cons and pros when making the decision.
>
> 1. As a library, when an API promises to developers that it keeps a timeout duration, it should try its best to keep the promise; For example, if developers invoke `send(message, 1s, cb)`, either cb called within 1s or cb is executed with TimeoutException the moment call get expired.
> 2. Things get tricky when the internal retry mechanism is involved. It is too easy to fail the promise now.
> 3. After studying solutions of other projects, say [gRPC client retry](https://github.com/grpc/proposal/blob/master/A6-client-retries.md), it is more reasonable to refine the semantics of the timeout in the API as **timeout of the internal RPC** and respect client timeout at the same time.
I agree with you.
I've known you for years on QQ. See you again.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lizhanhui commented on issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
lizhanhui commented on issue #4838:
URL: https://github.com/apache/rocketmq/issues/4838#issuecomment-1225094520
Amazing... It has been 6 or 7 years, but I still remember the days, when we, the early developers and adopters, share experiences and hunted bugs collaboratively.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] RongtongJin commented on issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
RongtongJin commented on issue #4838:
URL: https://github.com/apache/rocketmq/issues/4838#issuecomment-1219157231
Logically, I think it is reasonable for the current code to calculate the timeout time.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lwclover commented on issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
lwclover commented on issue #4838:
URL: https://github.com/apache/rocketmq/issues/4838#issuecomment-1219180205
I think it's reasonable to calculate the sending timeout after a message enters the thread pool.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lizhanhui commented on issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
lizhanhui commented on issue #4838:
URL: https://github.com/apache/rocketmq/issues/4838#issuecomment-1223794431
@15712852007 @lwclover I am the original designer of this scheme. Here are the cons and pros when making the decision.
1. As a library, when an API promises to developers that it keeps a timeout duration, it should try its best to keep the promise; For example, if developers invoke `send(message, 1s, cb)`, either cb called within 1s or cb is executed with TimeoutException the moment call get expired.
2. Things get tricky when the internal retry mechanism is involved. It is too easy to fail the promise now.
3. After studying solutions of other projects, say [gRPC client retry](https://github.com/grpc/proposal/blob/master/A6-client-retries.md), it is more reasonable to refine the semantics of the timeout in the API as **timeout of the internal RPC** and respect client timeout at the same time.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lizhanhui closed issue #4838: send async, time calculation problem
Posted by GitBox <gi...@apache.org>.
lizhanhui closed issue #4838: send async, time calculation problem
URL: https://github.com/apache/rocketmq/issues/4838
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org