预匹配请求过滤器中执行Panache阻塞调用报错的解决方案咨询

问题核心 #

@PreMatching过滤器默认运行在IO线程，即使在生产者方法上添加@Blocking注解，由于注入时机是在IO线程上下文，生产者方法仍会在IO线程执行，触发阻塞操作不允许的错误。以下是几种不影响现有阻塞代码的解决思路：

方法1：手动切换到工作线程执行查询 #

通过Vert.x的executeBlocking将Panache查询逻辑切换到工作线程执行，同步获取结果后再处理请求：

@Provider
@PreMatching
public class MyFilter implements ContainerRequestFilter {

    @Inject
    Vertx vertx;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        // 同步执行阻塞查询，强制切换到工作线程
        Boolean isAllowed = vertx.executeBlocking(promise -> {
            // 这里复用原有Panache查询逻辑
            MyPanacheObj obj = MyPanacheObj.find(query).firstResult();
            promise.complete(obj.isAllowed());
        }).toCompletionStage().toCompletableFuture().join();

        if (!isAllowed) {
            requestContext.abortWith(Response.status(403).build());
        }
    }
}

这种方式无需修改现有MyObj及生产者代码，直接在过滤器内完成线程切换，适配现有阻塞逻辑。

方法2：改用异步过滤器+Uni自动切换线程 #

将过滤器改为异步模式，利用Quarkus的Uni自动切换到工作线程执行阻塞操作，同时复用现有业务逻辑：

1. 封装阻塞查询到单独的Service Bean：

@ApplicationScoped
public class AccessControlService {

    @Blocking
    public boolean isAllowed() {
        // 复用原有Panache查询逻辑
        MyPanacheObj obj = MyPanacheObj.find(query).firstResult();
        return obj.isAllowed();
    }
}

2. 修改过滤器实现AsyncContainerRequestFilter：

@Provider
@PreMatching
public class MyFilter implements AsyncContainerRequestFilter {

    @Inject
    AccessControlService accessControlService;

    @Override
    public void filter(ContainerRequestContext requestContext, AsyncResponse asyncResponse) {
        accessControlService.isAllowed()
                .subscribe().with(
                        isAllowed -> {
                            if (!isAllowed) {
                                asyncResponse.resume(Response.status(403).build());
                            } else {
                                asyncResponse.resume(requestContext);
                            }
                        },
                        throwable -> asyncResponse.resume(Response.status(500).entity(throwable.getMessage()).build())
                );
    }
}

这种方式既保留了原有阻塞代码的复用性，又通过Quarkus的Reactive API自动完成线程切换，避免IO线程阻塞。

关键原因解析 #

@PreMatching过滤器的执行上下文固定为IO线程，CDI生产者方法的@Blocking注解仅在工作线程上下文调用时才会触发线程切换。而@RequestScoped Bean的注入会在当前线程（IO线程）触发生产者方法执行，导致@Blocking注解失效，进而触发错误。

内容的提问来源于stack exchange，提问作者nogridbag