fireUserEventTrigger 是使用 netty pipline "glue"非 netty 回调提供服务的正确方法吗?



大家好!

想知道是否使用fireUserEventTriggered/userEventTriggered在通道处理程序中处理消息时,是否有netty方法与面向回调的外部服务协作?

我的意思是,如果有一些"外星人"使用非阻塞(回调机制)方法的服务,这是调用ChannelHandlerContext#fireUserEventTriggered的正确方法吗?(从回调闭包中传递一些参数)然后在重载ChannelInboundHandler#userEventTriggered中处理它在原来的渠道中继续沟通,一切都开始了。

插图示例

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
externalServiceWithAsyncApi.doAndRegisterCallback(
//some call that will finish later and trigger callback handler
(callbackParam)-> 
ctx.fireUserEventTriggered(
new ExternalServiceCallbackEvent(callbackParam)
)
);
}
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
//seems its for us to handle
if (evt instanceof ExternalServiceCallbackEvent) {
//some processing and answer in the original?
ctx.channel()
.writeAndFlush(...)
.addListener(...);
// let other handlers process
} else {
super.userEventTriggered(ctx, evt);
}
}

在"Netty in Action"(在清单11.7中)是相关的,但是这部分内容有点超出了我当前的阅读点,因此决定请求帮助。

有一个非常类似的问题,但是有些东西不工作,没有回答Netty,从非Netty线程写通道

乌利希期刊指南

正确的方法似乎是调用NOT
ctx.fireUserEventTriggered(...)

,

ctx.channel().pipeline().fireUserEventTriggered(...)

你绝对可以用它。也就是说,你也可以直接从回调中进行写操作。

最新更新