-
Notifications
You must be signed in to change notification settings - Fork 859
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve: write and flush methods are provided #346
Conversation
WalkthroughThe recent modifications enhance the functionality of the Changes
Recent Review DetailsConfiguration used: CodeRabbit UI Files selected for processing (1)
Additional comments not posted (3)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
我觉得使用 ctx#getChannelContext 挺好的,这代表你已经使用了 Netty 的特性了, 超出了bolt 的范畴. 减少了误用RemotingContext 的可能性 |
如果是这样的设计,为什么还要对外单独开放一个writeAndFlush呢?我觉得如果要做的比较合理,比如屏蔽一些容易误操作的功能,应该把可用功能开放,风险高的功能封闭,或者框架层调优,无需用户去感知。 |
在我看来, writeAndFlush 并不是一个高风险的方法; 但是 write 和 flush 的组合就是一个比较容易出错的组合. Bolt 屏蔽了很多 Netty 的细节, 所以我们也不能默认 Bolt 的使用者对于 netty 很熟悉, 分别引入 write 和 flush 方法的必要性不是很大. |
看了下,感觉每个人理解不一样,我是感觉RemotingContext这里不应该提供getChannelContext方法,而是把必要的方法、属性按需开放出来更合理,我看代码里这个方法基本都是为了获取远程地址String remotingAddress = RemotingUtil.parseRemoteAddress(ctx.getChannelContext() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
https://github.com/funky-eyes/redispike-proxy
自己写的一个解析redis协议写入aerospike的代理程序,依赖sofa-bolt。支持redispippline时,需要批量响应,接收N个消息后,需要最后一个消息写完再flush,而sofa-bolt目前无法直接调用到write和单独的flush故此pr开放相关功能,并且利用这个功能,理论上也可以优化吞吐量,比如dubbo3.2的10倍性能提升就是通过先投入内存队列,然后异步从队列pop,将队列中同一时刻的请求全部先write,然后执行flush。
直接使用ctx#getChannelContext 粒度有点大,也不太优雅
Summary by CodeRabbit