如何在 Wildfly 8.2 中寻找模糊的 HA 集群错误。0.Final
How to hunt down obscure HA clustering bug in Wildfly 8.2.0.Final
设置
我有一个 Wildfly 8.2。0.Final 应用程序服务器 运行 一个使用 full-ha 配置文件的域模式集群。该集群由两个 wildfly 实例组成，master 和 slave，每个 运行 在自己的虚拟机上。
申请
我的项目在应用程序服务器上部署为 war-file。出于测试目的，我的负载均衡器使用 round-robin.
分配请求
匿名用户可以通过一个按钮使用本项目提供的服务，该按钮将分两步调用，先注册后登录。登录将使用在注册阶段创建的 session，提供在注册调用期间创建的凭据。
实施
登录端点是一个请求范围的 CDI bean，在其他成员中有一个成员保存用户信息。用户信息是一个 SessionScopped EJB Bean，它是在 session 实例化期间创建的，并被注入到登录端点 CDI bean 中。用户信息应该在集群成员之间分发。
观察到的行为
现在是有趣的部分：
- 使用 Firefox：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 在隐私模式下使用 Firefox：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 使用Chrome：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 在私人模式下使用Chrome：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 使用 Internet Explorer 11：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 在隐私模式下使用 Internet Explorer 11：
- /rest/register -> 200 行
- /rest/login -> 500 内部服务器错误
日志
这是 500 的堆栈跟踪：
2015-05-07 10:05:31,734 ERROR [io.undertow.request] (default task-11) UT005023: Exception handling request to /testtest/rest/login: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.10.Final.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access[=11=]0(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
Caused by: java.lang.NullPointerException
at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at ru.exampl.testtest.lobby.UserController$Proxy$_$$_WeldClientProxy.toString(Unknown Source) [classes:]
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:106) [log4j-jboss-logmanager-1.1.0.Final.jar:1.1.0.Final]
at org.apache.log4j.Category.forcedLog(Category.java:119) [log4j-jboss-logmanager-1.1.0.Final.jar:1.1.0.Final]
at org.apache.log4j.Category.debug(Category.java:80) [log4j-jboss-logmanager-1.1.0.Final.jar:1.1.0.Final]
at ru.exampl.testtest.rest.LobbyEndpoint.login(LobbyEndpoint.java:100) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.10.Final.jar:]
密码
这是导致错误的相关代码（或者在它正常工作的情况下无效）：
package ru.exampl.testtest.rest;
[... lots of imports ...]
/**
* The implementation of some general webservice endpoints.
*/
@RequestScoped
@Path("rest")
public class LobbyEndpoint {
private transient static final Logger log4j = Logger.getLogger(LobbyEndpoint.class);
@Inject
private UserController userController;
[... more injections ...]
@POST
@Path("/login")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public LoginResponse login(LoginRequest request) {
log4j.log(userController);
[... lots of code to handle login ...]
}
}
现在有趣的是，userController 显然不是空的，因为 log4j 知道如何处理和记录空的 object。 object 显然有一个引用，但 Weld 无法通过代理访问它。如果没有浏览器列表，这本身就只有一半有趣，在这些浏览器中，这个完全相同的休息端点正在完成它的工作，并且只有一个特定的浏览器处于一种特定的浏览器模式导致 webapp 崩溃。
附加信息
老实说，我不知道浏览器如何通过其请求引发这种行为。但为了让事情变得更有趣，我用 tshark 记录了实际请求，然后修改了 Firefox 以发送与 Internet Explorer 11 发送的完全相同的请求。现在请屏住呼吸：在所有情况相同的情况下，Firefox 不会使 Web 应用程序崩溃，而处于私有模式的 Internet Explorer 11 在 100% 的时间内都会崩溃。
我记录了两个请求来演示（你可以在wireshark中查看）：
- Internet Explorer 11 in private mode
- Firefox in private mode faking IE 11 user agent and language settings
实际问题
现在我的问题是：我从哪里开始调试它？
如果整个请求除了headers的顺序？不涉及时间。在请求中引入随机等待并没有改变任何东西。
我有一个类似的堆栈跟踪。但是我忘记在我的 wildfly 配置的 undertow 部分设置 "instance-id" 。只要服务器没有尝试复制会话，问题就不会出现。
所以我的解决方案就是像这样简单地设置一个实例 ID：
<subsystem xmlns="urn:jboss:domain:undertow:1.2" instance-id="${jboss.server.name}">
这也可以通过 jboss-cli 设置：
/profile=full-ha/subsystem=undertow:write-attribute(name=instance-id, value="${jboss.server.name}")
[编辑：试图找到解释]
此语句发生 NullpointerException：
lockStore = (LockStore) session.getAttribute(SESSION_KEY);
在此语句中，仅当 "session" 为空时才会发生 NPE。 "session" 对象是通过调用由子 class 实现的 getSession() 方法较早获取的。我可以找到两个可能的候选人：
- LazySessionBeanStore (org.jboss.weld.context.beanstore.http)
- LazyCyclicSessionBeanStore (org.jboss.weld.context.beanstore.http)
- EagerSessionBeanStore (org.jboss.weld.context.beanstore.http)
我不明白为什么那些 classes 可以 return 为 "session" null。以及这与设置 untertow 部分中的 "instance-id" 有何关联。我所看到的是，许多日志记录语句都是在这些地方创建的。为了更进一步，我会尝试在 "org.jboss.weld".
上将日志级别设置为 "TRACE"
设置
我有一个 Wildfly 8.2。0.Final 应用程序服务器 运行 一个使用 full-ha 配置文件的域模式集群。该集群由两个 wildfly 实例组成，master 和 slave，每个 运行 在自己的虚拟机上。
申请
我的项目在应用程序服务器上部署为 war-file。出于测试目的，我的负载均衡器使用 round-robin.
分配请求匿名用户可以通过一个按钮使用本项目提供的服务，该按钮将分两步调用，先注册后登录。登录将使用在注册阶段创建的 session，提供在注册调用期间创建的凭据。
实施
登录端点是一个请求范围的 CDI bean，在其他成员中有一个成员保存用户信息。用户信息是一个 SessionScopped EJB Bean，它是在 session 实例化期间创建的，并被注入到登录端点 CDI bean 中。用户信息应该在集群成员之间分发。
观察到的行为
现在是有趣的部分：
- 使用 Firefox：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 在隐私模式下使用 Firefox：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 使用Chrome：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 在私人模式下使用Chrome：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 使用 Internet Explorer 11：
- /rest/register -> 200 行
- /rest/login -> 200 行
- 在隐私模式下使用 Internet Explorer 11：
- /rest/register -> 200 行
- /rest/login -> 500 内部服务器错误
日志
这是 500 的堆栈跟踪：
2015-05-07 10:05:31,734 ERROR [io.undertow.request] (default task-11) UT005023: Exception handling request to /testtest/rest/login: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.10.Final.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access[=11=]0(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
Caused by: java.lang.NullPointerException
at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
at ru.exampl.testtest.lobby.UserController$Proxy$_$$_WeldClientProxy.toString(Unknown Source) [classes:]
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:106) [log4j-jboss-logmanager-1.1.0.Final.jar:1.1.0.Final]
at org.apache.log4j.Category.forcedLog(Category.java:119) [log4j-jboss-logmanager-1.1.0.Final.jar:1.1.0.Final]
at org.apache.log4j.Category.debug(Category.java:80) [log4j-jboss-logmanager-1.1.0.Final.jar:1.1.0.Final]
at ru.exampl.testtest.rest.LobbyEndpoint.login(LobbyEndpoint.java:100) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.10.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.10.Final.jar:]
密码
这是导致错误的相关代码（或者在它正常工作的情况下无效）：
package ru.exampl.testtest.rest;
[... lots of imports ...]
/**
* The implementation of some general webservice endpoints.
*/
@RequestScoped
@Path("rest")
public class LobbyEndpoint {
private transient static final Logger log4j = Logger.getLogger(LobbyEndpoint.class);
@Inject
private UserController userController;
[... more injections ...]
@POST
@Path("/login")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public LoginResponse login(LoginRequest request) {
log4j.log(userController);
[... lots of code to handle login ...]
}
}
现在有趣的是，userController 显然不是空的，因为 log4j 知道如何处理和记录空的 object。 object 显然有一个引用，但 Weld 无法通过代理访问它。如果没有浏览器列表，这本身就只有一半有趣，在这些浏览器中，这个完全相同的休息端点正在完成它的工作，并且只有一个特定的浏览器处于一种特定的浏览器模式导致 webapp 崩溃。
附加信息
老实说，我不知道浏览器如何通过其请求引发这种行为。但为了让事情变得更有趣，我用 tshark 记录了实际请求，然后修改了 Firefox 以发送与 Internet Explorer 11 发送的完全相同的请求。现在请屏住呼吸：在所有情况相同的情况下，Firefox 不会使 Web 应用程序崩溃，而处于私有模式的 Internet Explorer 11 在 100% 的时间内都会崩溃。
我记录了两个请求来演示（你可以在wireshark中查看）：
- Internet Explorer 11 in private mode
- Firefox in private mode faking IE 11 user agent and language settings
实际问题
现在我的问题是：我从哪里开始调试它？ 如果整个请求除了headers的顺序？不涉及时间。在请求中引入随机等待并没有改变任何东西。
我有一个类似的堆栈跟踪。但是我忘记在我的 wildfly 配置的 undertow 部分设置 "instance-id" 。只要服务器没有尝试复制会话，问题就不会出现。
所以我的解决方案就是像这样简单地设置一个实例 ID：
<subsystem xmlns="urn:jboss:domain:undertow:1.2" instance-id="${jboss.server.name}">
这也可以通过 jboss-cli 设置：
/profile=full-ha/subsystem=undertow:write-attribute(name=instance-id, value="${jboss.server.name}")
[编辑：试图找到解释]
此语句发生 NullpointerException：
lockStore = (LockStore) session.getAttribute(SESSION_KEY);
在此语句中，仅当 "session" 为空时才会发生 NPE。 "session" 对象是通过调用由子 class 实现的 getSession() 方法较早获取的。我可以找到两个可能的候选人：
- LazySessionBeanStore (org.jboss.weld.context.beanstore.http)
- LazyCyclicSessionBeanStore (org.jboss.weld.context.beanstore.http)
- EagerSessionBeanStore (org.jboss.weld.context.beanstore.http)
我不明白为什么那些 classes 可以 return 为 "session" null。以及这与设置 untertow 部分中的 "instance-id" 有何关联。我所看到的是，许多日志记录语句都是在这些地方创建的。为了更进一步，我会尝试在 "org.jboss.weld".
上将日志级别设置为 "TRACE"