Блог

Версия: jboss-eap-7.2.4

вот standalone.xml часть конфигурации для ведения журнала, в основном, есть обработчик файлов с вращением двух размеров в качестве подобработчика асинхронного обработчика.

  <subsystem xmlns="urn:jboss:domain:logging:6.0">
        <async-handler name="ASYNC">
            <queue-length value="8192"/>
            <overflow-action value="block"/>
            <subhandlers>
                <handler name="FILE"/>
                <handler name="MetricLogger"/>
            </subhandlers>
        </async-handler>

        <size-rotating-file-handler name="FILE" autoflush="true">
          <filter-spec value="not(match(amp;quot;application-metrics.*amp;quot;))"/>
          <formatter>
             <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss,SSS} %5p [CMS] [%t] %C{1}.%M() - %m%n"/>
          </formatter>
          <file path="/opt/application/log/application.log"/>
          <rotate-size value="10m"/>
          <max-backup-index value="100"/>
          <append value="true"/>
       </size-rotating-file-handler>
       <size-rotating-file-handler name="MetricLogger" autoflush="true">
         <filter-spec value="all(match(amp;quot;application-metrics.*amp;quot;))"/>
        <formatter>
           <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss,SSS} %5p [METRICS] - %m%n"/>
        </formatter>
        <file path="/opt/application/log/application-metrics.log"/>
        <rotate-size value="10m"/>
        <max-backup-index value="10"/>
        <append value="true"/>
      </size-rotating-file-handler>
 

сначала он может успешно запуститься и может распечатать журнал в файлы, но после некоторого запуска он выдаст исключение ниже, и jboss завершит работу…

 java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.rollback(AbstractPropertyConfiguration.java:244)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.doForget(LogContextConfigurationImpl.java:355)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.forget(LogContextConfigurationImpl.java:319)
        at org.jboss.as.logging.logmanager.ConfigurationPersistence.forget(ConfigurationPersistence.java:341)
        at org.jboss.as.logging.logmanager.ConfigurationPersistence.rollback(ConfigurationPersistence.java:349)
        at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler$1.handleResult(LoggingOperations.java:122)
        at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1533)
        at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1515)
        at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1472)
        at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1455)
        at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1319)
        at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:876)
        at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
        at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
        at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:470)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:432)
        at org.jboss.as.server.ServerService.boot(ServerService.java:427)
        at org.jboss.as.server.ServerService.boot(ServerService.java:386)
        at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
        at java.lang.Thread.run(Thread.java:748)
 
 Caused by: java.lang.NullPointerException: overflowAction is null
         at org.jboss.logmanager.handlers.AsyncHandler.setOverflowAction(AsyncHandler.java:117)
         ... 26 more No property "queueLength" type could be determined for handler "ASYNC"
 

У нас была такая же проблема в нашей команде после обновления до Wildfly 18 (у нас было много версий, трудно сказать, какая именно версия ее вызвала).

Решением для нас было убедиться, что файл logging.properties был правильно сгенерирован на основе нашего standalone.xml , поскольку это своего рода резервная конфигурация ведения журнала до тех пор, пока подсистема не запустится во время запуска.

Генерация, в свою очередь, выполняется, когда standalone.sh/bat выполняется. У нас все еще остаются некоторые открытые вопросы:

1. Почему это требование сейчас? У нас никогда раньше не заполнялся файл logging.properties.
2. Какой именно шаг standalone.sh скрипт запускает генерацию файла logging.properties. Это то, что мы в настоящее время оцениваем для включения в наш пользовательский процесс запуска.