lizhanhui opened a new issue, #4437: URL: https://github.com/apache/rocketmq/issues/4437
RocketMQ attempts to implement [Intercepting Filter](https://www.oracle.com/technetwork/java/interceptingfilter-142169.html), providing flexibility of executing the hook pipeline before and after each RPC request. See https://github.com/apache/rocketmq/blob/73b9ac82bcd14b2a40ba31888a96e62d06d42d92/remoting/src/main/java/org/apache/rocketmq/remoting/netty/NettyRemotingAbstract.java#L169 https://github.com/apache/rocketmq/blob/73b9ac82bcd14b2a40ba31888a96e62d06d42d92/remoting/src/main/java/org/apache/rocketmq/remoting/netty/NettyRemotingAbstract.java#L177 The overall pattern is awesome while the implementation is pretty limited. ```java public interface RPCHook { void doBeforeRequest(final String remoteAddr, final RemotingCommand request); void doAfterResponse(final String remoteAddr, final RemotingCommand request, final RemotingCommand response); } ``` Comparing similar yet better implementation in Netty: https://github.com/netty/netty/blob/d34212439068091bcec29a8fad4df82f0a82c638/transport/src/main/java/io/netty/channel/ChannelPipeline.java#L32 Current RocketMQ implementation is incapable of stopping processing at premature stages. This limitation results in ugly implementation of features like Authentication, Authorization. Assume a request is found forbidden in the RpcHook implementation, It can only interrupt the execution through throwing exceptions. [Exceptions are not intended for flow control](https://dzone.com/articles/exceptions-as-controlflow-in-java) and handling of the exception in the NettyRemotingServer is also challenging, additionally, this may also impose risks of flooding our logging files. -- 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]
