dugenkui03 commented on issue #3973: URL: https://github.com/apache/rocketmq/issues/3973#issuecomment-1092463886
Thanks for your reply, there is already a pr for these suggestion #4134. **If some work is already done, please ignored #4134**. > CompletableFuture may be essential, which allows users add their callback easily. Return `Future` will not stop developers use callback in `CompletableFuture` because `CompletableFuture` is a implementation of `Future`. but return a concret `CompletableFuture` will affect the extensibility of the interface —— You must accept both pros and cons, such as async timeout, and it is hard to extend `CompletableFuture`. >In most case, BackoffRetryPolicy is enough. If `BackoffRetryPolicy` could satify developers, I think `RetryPolicy` will be redundant. The reason I think `RetryPolicy` is better is that **Developers will always want to change `maxAttempts`**. #### Describe in Chinese 感谢回复，针对这些建议当前已经有了一个pr、见#4134，如果有相关的代码已经实现或者正在进行中则请忽略该PR。 > CompletableFuture may be essential, which allows users add their callback easily. 返回`Future`并不影响开发者在后续处理中使用`CompletableFuture`中提供的回调方法、因为开发者可以在具体的视线中返回`Futrue`的实现类`CompletableFuture`。但是返回具体的类将会影响该接口的可扩展性、也意味着我们必须同时接受`CompletableFuture`的优缺点、例如异步超时机制在jdk1.9才出现、而该特性对于超时发送也许会很重要； >In most case, BackoffRetryPolicy is enough. 如果`BackoffRetryPolicy`已经能够应对各种场景那`RetryPolicy`的定义似乎有些多余？ 我认为`RetryPolicy`使用比较恰当的原因是开发者总是想动态的修改`maxAttempts`(比如通过redis或者公司各种配置平台配置系统的一些关键参数)。`nextAttemptDelay`同理。 -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
