Tomcat - 异步请求的 WELD 解决方法答案

【问题标题】：Tomcat - WELD workaround for asynchronous requestsTomcat - 异步请求的 WELD 解决方法
【发布时间】：2018-11-02 13:29:59
【问题描述】：

我有一个使用 WELD 3.0.5 和 RestEasy 3.6.1 在 Tomcat 9 上运行的 REST 应用程序。

对于异步请求，Tomcat 在与触发初始化事件的线程不同的线程中触发请求销毁事件。在这种情况下，使用ThreadLocals 的 WELD 不会停用请求上下文，因此不会调用 bean 处理方法。

见：What do WELD-000225, WELD-000335 and WELD-000715 warnings mean?

和 Tomcat Bug 57314

我的应用程序依赖于容器生命周期事件来关闭资源并进行清理，因此我需要一种方法来使异步请求的一切工作也正常。我想出的解决方案是在执行链末尾添加一个WebFilter，使当前请求上下文无效。

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws Exception {

    BeanManager beanManager = CDI.current().getBeanManager();
    AlterableContext context = (AlterableContext) beanManager.getContext(RequestScoped.class);
    try {
        chain.doFilter(request, response);
    } finally {
        if (request.isAsyncStarted()) {
            AbstractBoundContext<?> ctxt = (AbstractBoundContext<?>) delegate;
            ctxt.invalidate();
            ctxt.deactivate();
            ctxt.cleanup();
        }
    }
}

这在丢弃 bean 和删除一些线程局部变量方面做得很好。不幸的是，一些变量仍然与池线程相关联 Tomcat 抱怨它：

SEVERE: The web application [cdi-weld] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3d97cd8b]) and a value of type [org.jboss.weld.module.web.servlet.HttpContextLifecycle.Counter] (value [org.jboss.weld.module.web.servlet.HttpContextLifecycle$Counter@43a15b16]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Nov 02, 2018 10:43:55 AM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks
SEVERE: The web application [cdi-weld] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@21d33dd8]) and a value of type [org.jboss.weld.contexts.AbstractManagedContext.ManagedState] (value [org.jboss.weld.contexts.AbstractManagedContext$ManagedState@2a336421]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Nov 02, 2018 10:43:55 AM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks
SEVERE: The web application [cdi-weld] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@294b0f79]) and a value of type [org.jboss.weld.module.web.servlet.ConversationContextActivator$$Lambda$555/1676983761] (value [org.jboss.weld.module.web.servlet.ConversationContextActivator$$Lambda$555/1676983761@60fb88ad]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

我的理解是每个请求都会覆盖 ThreadLocals，所以这并不完全是内存泄漏，但我仍然对这个解决方案不是 100% 满意。

有人知道解决此问题的更好方法吗？

【问题讨论】：

标签： tomcat cdi weld2

【解决方案1】：

以下信息不是我尝试过的解决方案，但它是我最好的解决方法。

org.jboss.weld.module.web.servlet.HttpContextLifecycle.Counter你可能无法修复，或者至少我不知道如何修复。

但是其他两个是不同的上下文，您可以通过像使用请求上下文一样停用它们来解决它。

org.jboss.weld.contexts.AbstractManagedContext.ManagedState 您将不得不深入研究这实际上是什么背景。会话或对话是我的猜测。尝试使用BeanManager 检索您知道的范围的上下文并查看。一点点调试就大有帮助。

org.jboss.weld.module.web.servlet.ConversationContextActivator$$Lambda$555/1676983761 这应该是对话上下文（可能是LazyHttpConversationContextImpl）。释放该上下文可能会使这种情况消失。

【讨论】：

你是对的。如果我清理 Session 和 Conversation 上下文，我会摆脱大多数线程本地变量。最后我只剩下柜台了。我希望有更好的解决方法。
好吧，Weld 不能为你做很多事情，因为它与 servlet 无关并且不知道 Tomcat。除了 IMO 之外，Tomcat 在这里做错了......