Подтвердить что ты не робот

Как выследить непонятную HA-кластерную ошибку в Wildfly 8.2.0.Final

Настройка

У меня есть Wildfly 8.2.0.Финантный сервер приложений, работающий с кластером в режиме домена с использованием профиля full-ha. Кластер состоит из двух экземпляров wildfly, master и slave, каждый из которых работает на собственной виртуальной машине.

Приложение

Мой проект развертывается как военный файл на сервере приложений. В тестовых целях мой loadbalancer распределяет запросы с использованием циклического режима.

Анонимные пользователи могут использовать услугу, предоставляемую этим проектом, с помощью кнопки, которая будет вызывать в два этапа первый регистр, а затем войти в систему. Вход будет использоваться для сеанса, который создается во время фазы регистрации, предоставляя учетные данные, созданные во время вызова регистра.

Реализация

Конечная точка входа - это CDI bean с ограниченным запросом, который среди других членов имеет член, который содержит информацию о пользователе. Пользовательская информация представляет собой SessionScopped EJB Bean, который создается во время создания сеанса и который вводится в конечные точки входа в систему CDI bean. Предполагается, что информация о пользователе будет распределена между членами кластера.

Наблюдаемое поведение

Теперь смешная часть:

  • Использование Firefox:
    1. /rest/register → 200 OK
    2. /rest/login → 200 OK
  • Использование Firefox в приватном режиме:
    1. /rest/register → 200 OK
    2. /rest/login → 200 OK
  • Использование Chrome:
    1. /rest/register → 200 OK
    2. /rest/login → 200 OK
  • Использование Chrome в приватном режиме:
    1. /rest/register → 200 OK
    2. /rest/login → 200 OK
  • Использование Internet Explorer 11:
    1. /rest/register → 200 OK
    2. /rest/login → 200 OK
  • Использование Internet Explorer 11 в приватном режиме:
    1. /rest/register → 200 OK
    2. /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$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.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$1.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 знает, как обрабатывать и регистрировать нулевые объекты. Объект, очевидно, имеет ссылку, но Weld не может получить к нему доступ через прокси. Это само по себе было бы вдвойне смешнее без списка браузеров, где эта же конечная точка останова выполняет свою работу и только один конкретный браузер в одном конкретном режиме браузера, из-за которого происходит сбой webapp.

Дополнительная информация

Честно говоря, я НЕ знаю, как браузер через свои запросы может спровоцировать такое поведение. Но чтобы сделать вещи еще более забавными, я записал фактические запросы с tshark, а затем изменил Firefox, чтобы отправить тот же запрос, который отправляет Internet Explorer 11. И теперь задерживайте дыхание: при прочих равных условиях Firefox не разбивает webapp, а Internet Explorer 11 в частном режиме - в 100% случаев.

Я записал оба запроса для демонстрации (вы можете просмотреть их в wirehark):

Фактический вопрос

Теперь мой вопрос: где я даже начинаю отлаживать это? Как веб-браузер, отправляющий свои запросы через прокси-сервер, даже оказывает малейшее влияние на результат моей синхронизации сеансов в моем кластере и, таким образом, влияет на обработку запросов на моем сервере приложений, если весь запрос идентичен, за исключением порядка заголовков? Сроки не задействованы. Представление случайных ожиданий в запросах ничего не изменило.

4b9b3361

ОТВЕТЫ

Ответ 1

У меня была аналогичная трассировка стека. Но я забыл установить "экземпляр-id" в разделе "Подъем" моей конфигурации wildfly. Проблема не возникла, если сервер не пытался реплицировать сеанс.

Итак, решение для меня просто устанавливало идентификатор экземпляра:

<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);

В этом утверждении NPE произойдет, только если "session" имеет значение null. Объект "сеанс" приобретается ранее, вызывая метод getSession(), который реализуется дочерним классом. Я могу найти двух возможных кандидатов:

  • LazySessionBeanStore (org.jboss.weld.context.beanstore.http)
  • LazyCyclicSessionBeanStore (org.jboss.weld.context.beanstore.http)
  • EagerSessionBeanStore (org.jboss.weld.context.beanstore.http)

Мне не кажется очевидным, почему эти классы могут возвращать значение null для "сессии". И как это связано с установкой "instance-id" в разделе untertow. Я вижу, что в них создаются многие записи ведения журнала. Чтобы продолжить дальше, я попытался установить уровень журнала на "TRACE" на "org.jboss.weld".