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 2020/12/04 13:42:39 UTC
[GitHub] [rocketmq] fantow opened a new issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
fantow opened a new issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486
**BUG REPORT**
1. Please describe the issue you observed:
**I don't think that initialize a Response's beginTimeStamp when it is stated is a good idea.Because we will use this field to determine if it timed out.
There are many reasons may cause sent delay when we run a program in our machine.
And I think we can initialize this field when this RemotingCommand sent successfully in it's callback function.**
If this is a necessary issue,may I submit a PR to fix it?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] fantow commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
fantow commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-740467322
Thx,I agree with your answer when we use invoke funtion in a sync mode.
But as a user,I can not accept the send result is timeout when we send messages in an aync mode, this request can not get the sepahore in time.
In my opinion,timeout is used to limit the recv time ,not the send concurrency.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] Jaskey commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
Jaskey commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-740404767
@fantow 1ms is a very long time. When we use ResponseFuture, it should not have a chance to have more than 1ms for memory operations.
Do you find any usage that may result in wrong time span calculation?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] fantow commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
fantow commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-740440368
>
>
> @fantow 1ms is a very long time. When we use ResponseFuture, it should not have a chance to have more than 1ms for memory operations.
>
> Do you find any usage that may result in wrong time span calculation?
IMHO,this ResponseFuture's timeoutMillis may cause something wrong when our machine sends more messages.
First,because writeAndFlush will call this Listener only if message can send to socket buffer,there are many scene will cause send buffer overflowed.So I think there is a good time to initialize the beginTime that when we actually send message(Plz ignore the time waste between socket buffer to NIC).
Second,when we invoke the function invokAysnc(),Our send capacity will be limited by the semaphore of Aysnc,We will wait for this semaphore when we send a lot of messages.I do not think that waiting for a semaphore to send message can cause sending timeout is a good result.
That is why I think we should initial this ResponseFuture's beginTime when the future's state is success.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] Jaskey commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
Jaskey commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-741732563
@fantow In my opinion, it is the same for async request, after 3000ms I call the api, I should get a timeout exception in my callback method
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] fantow commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
fantow commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-741747605
>
>
> @fantow In my opinion, it is the same for async request, after 3000ms I call the api, I should get a timeout exception in my callback method
It seems that we have a different idea on should the lock acquisition time be counted as the total send timeout.
As a user,I think we should treat the semaphore acquisition time and time of request waiting for it's response diffirentially
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] vongosling closed issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
vongosling closed issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] fantow commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
fantow commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-740467554
>
>
> As a user, when you set a timeout of 3000ms, once he/she calls the api, if the api can not success after 3000ms, he/she should get a timeout exceptions.
>
> So even as you see, lots of messages may cost a 50ms delay sent, the user should got the expcetion after 3000ms rather than 3050ms
Thx,I agree with your answer when we use invoke funtion in a sync mode.
But as a user,I can not accept the send result is timeout when we send messages in an aync mode, this request can not get the sepahore in time.
In my opinion,timeout is used to limit the recv time ,not the send concurrency.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] fantow removed a comment on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
fantow removed a comment on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-740467322
Thx,I agree with your answer when we use invoke funtion in a sync mode.
But as a user,I can not accept the send result is timeout when we send messages in an aync mode, this request can not get the sepahore in time.
In my opinion,timeout is used to limit the recv time ,not the send concurrency.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] Jaskey commented on issue #2486: [Remoting]It is not a good chance to initialize a ResponseFuture‘s beginTimeStamp when it is stated.
Posted by GitBox <gi...@apache.org>.
Jaskey commented on issue #2486:
URL: https://github.com/apache/rocketmq/issues/2486#issuecomment-740458810
As a user, when you set a timeout of 3000ms, once he/she calls the api, if the api can not success after 3000ms, he/she should get a timeout exceptions.
So even as you see, lots of messages may cost a 50ms delay sent, the user should got the expcetion after 3000ms rather than 3050ms
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org